[EMAIL PROTECTED] (Eric W. Biederman) writes:
> There are a couple pieces of your example that disturb me.
Did you actually think I suggested you to make that into a
script that cannot be configured? No, it was Junio acquiring a
habit from Linus to give a rough outline in a code form in his
In another message, you said:
> Actually looking a little deeper unless I have misread
> the code git-fetch-pack at least will only ask for commit
> objects so git fetch will never return a tag object.
I thought so but then I tried it and actually it does seem to
work as expected (well, it is Linus code so it has to be perfect
;-). I created an empty directory and ran the following script.
It creates two commits, tags the later commit to
".git/refs/tags/one", and shows the list of objects the
upload-pack (the peer git-fetch-pack talks to) decides to pack
and send to the puller that has the first commit only. The
first git-rev-list shows one extra object compared to the second
one; the difference is the named tag that is being asked.
rm -fr .git
echo "base tree $zero_tree"
echo Empty tree as the base |
echo "base commit $zero_commit"
git-update-cache --add a
echo "one tree $one_tree"
echo Add one file |
git-commit-tree $one_tree -p $zero_commit
echo "one commit $one_commit"
echo "object $one_commit
just a tag." | git-mktag >.git/refs/tags/one
echo "one tag `cat .git/refs/tags/one`"
echo "*** reachable from one tag but not from zero"
git-rev-list --objects tags/one ^$zero_commit
echo "*** reachable from one commit but not from zero"
git-rev-list --objects $one_commit ^$zero_commit
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html