"Stefan-W. Hahn" <stefan.hahn@xxxxxxxxx> writes:
> Tracking it down, I found a gap between how git-ls-remote prints out the tags
> and git-fetch scans them with sed. Looking at the code of git-ls-remote the
> there is an tab character between the sha1 and the refname, while there is a
> space and a tab character in the regular expression for th sed command.
>
> As a result the while where all is piped in cannot read the two values.
Sorry.
I do not understand the above comment, nor the following code.
> git-ls-remote $upload_pack --tags "$remote" |
> - sed -ne 's|^\([0-9a-f]*\)[ ]\(refs/tags/.*\)^{}$|\1 \2|p' |
> + sed -ne 's|^\([0-9a-f]*\)[\t]\(refs/tags/.*\)^{}$|\1 \2|p' |
ls-remote shows "SHA1\tPATH". The original says "hexadecimal
followed by [either a single space or a single tab] followed by
a refpath", while yours says "hexadecimal followed by a single tab
followed by a refpath". I do not see how that would make any
difference. Puzzled...
I've seen two servers DNS round-robin and one of them fail to
respond. The first "fetch" goes to the good one and the second
ls-remote goes to the bad one, then you would see "Oops, we
cannot peek tags". But this patch does not have anything to do
with that problem..
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html