Re: [PATCH] git-revover-tags-script

ebiederm@xmission.com (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
e-mail client.

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.


------------
#!/bin/sh

rm -fr .git
git-init-db
zero_tree=$(git-write-tree)
echo "base tree $zero_tree"
zero_commit=$(
	echo Empty tree as the base |
	git-commit-tree $zero_tree
)
echo "base commit $zero_commit"

echo >a
git-update-cache --add a
one_tree=$(git-write-tree)
echo "one tree $one_tree"
one_commit=$(
	echo Add one file |
	git-commit-tree $one_tree -p $zero_commit
)
echo "one commit $one_commit"

tagger=$(git-var GIT_COMMITTER_IDENT)
echo "object $one_commit
type commit
tag tag-one
tagger $tagger

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