tracking branch on a tag

tracking branch on a tag

[Simon Braunschmidt]

Hi

So i set up a tracking branch on an annotated signed tag like:


$git branch --track foobranch v2.6.26
 >Branch foobranch set up to track local ref refs/tags/v2.6.26.

Check it out, get an error

$git checkout foobranch
 >Switched to branch 'foobranch'
 >error: Object 14650d6ec137e70b6c1918cdef235027c5156020 is a commit, 
not a tag
 >fatal: Invalid symmetric difference expression 
bce7f793daec3e65ec5c5705d2457b81fe7b5725...14650d6ec137e70b6c1918cdef235027c5156020

Inspect the relevant object

$git-cat-file -p bce7f793daec3e65ec5c5705d2457b81fe7b5725
 >tree 05bc81f9b27a1ab60ea4e506357f0c7f2ece4eda
 >parent ec229e830060091b9be63c8f873c1b2407a82821
 >author Linus Torvalds <torvalds@linux-foundation.org> 1215985889 -0700
 >committer Linus Torvalds <torvalds@linux-foundation.org> 1215985889 -0700

 >Linux 2.6.26

$git-cat-file -p 14650d6ec137e70b6c1918cdef235027c5156020
 >object bce7f793daec3e65ec5c5705d2457b81fe7b5725
 >type commit
 >tag v2.6.26
 >tagger Linus Torvalds <torvalds@linux-foundation.org> Sun Jul 13 
 >14:51:38 2008 -0700
 >
 >Linux 2.6.26
 >-----BEGIN PGP SIGNATURE-----
 >Version: GnuPG v1.4.9 (GNU/Linux)
 >
 >iEYEABECAAYFAkh6ePIACgkQF3YsRnbiHLuJcACgpHzd21qAY25V2VQWBCYPW8bB
 >Z8MAoJ9qfiwuRt27cdrmAU2aJq+YFrYs
 >=aHK8
 >-----END PGP SIGNATURE-----

I get this errors only on annotated/signed tags, not on lightweight 
tags. Admittedly it doesnt make much sense to track a tag, yet this 
error message makes even less sense:

error: Object 14650d6ec137e70b6c1918cdef235027c5156020 is a commit, not 
a tag

with 14650d being a tag.

Is this error message serious, as fatal sound quite harsh? Can it be 
avoided, by guiding the user on  branch creation or by simply not 
showing it in this situation?

Gruessle
Simon

[PATCH] Fix behavior with non-committish upstream references

[Michael J Gruber]

stat_tracking_info() assumes that upstream references (as specified by
--track or set up automatically) are commits. By calling lookup_commit()
on them, create_objects() creates objects for them with type commit no
matter what their real type is; this disturbs lookup_tag() later on the
call sequence, leading to git status, git branch -v  and git checkout
erroring out.

Fix this by using lookup_commit_reference() instead so that (annotated)
tags can be used as upstream references.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
I'm sorry I won't be able to write a test any more today. Please let me
whether it's okay without a test.

 remote.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/remote.c b/remote.c
index d66e2f3..2c3e905 100644
--- a/remote.c
+++ b/remote.c
@@ -1399,13 +1399,13 @@ int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)
 	base = branch->merge[0]->dst;
 	if (!resolve_ref(base, sha1, 1, NULL))
 		return 0;
-	theirs = lookup_commit(sha1);
+	theirs = lookup_commit_reference(sha1);
 	if (!theirs)
 		return 0;
 
 	if (!resolve_ref(branch->refname, sha1, 1, NULL))
 		return 0;
-	ours = lookup_commit(sha1);
+	ours = lookup_commit_reference(sha1);
 	if (!ours)
 		return 0;
 
-- 
1.6.3.rc3

Re: [PATCH] Fix behavior with non-committish upstream references

[Junio C Hamano]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> stat_tracking_info() assumes that upstream references (as specified by
> --track or set up automatically) are commits. By calling lookup_commit()
> on them, create_objects() creates objects for them with type commit no
> matter what their real type is; this disturbs lookup_tag() later on the
> call sequence, leading to git status, git branch -v  and git checkout
> erroring out.
>
> Fix this by using lookup_commit_reference() instead so that (annotated)
> tags can be used as upstream references.
>
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> ---
> I'm sorry I won't be able to write a test any more today. Please let me
> whether it's okay without a test.

I am sorry, but I simply do not see much point in this.  I think you meant
by the title "non-commit upstream ref", as a tag that eventually peels to
a commit is a committish.  Because a tag is meant to be immutable, forking
from that mean your further "merges from upstream" won't do anything, so
the current behaviour of returning without saying anything sounds like the
right thing to do, even though I strongly suspect that it behaves this way
by accident not by design.

Admittedly, I do not "fork and keep up-to-date with an upstream" that
often, so I am in no way making a final decision here.  It would be
healthy for interested people to discuss this patch, but I'd appreciate it
if it happens after 1.6.3 final.

Re: [PATCH] Fix behavior with non-committish upstream references

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 28.04.2009 09:30:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> stat_tracking_info() assumes that upstream references (as specified by
>> --track or set up automatically) are commits. By calling lookup_commit()
>> on them, create_objects() creates objects for them with type commit no
>> matter what their real type is; this disturbs lookup_tag() later on the
>> call sequence, leading to git status, git branch -v  and git checkout
>> erroring out.
>>
>> Fix this by using lookup_commit_reference() instead so that (annotated)
>> tags can be used as upstream references.
>>
>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
>> ---
>> I'm sorry I won't be able to write a test any more today. Please let me
>> whether it's okay without a test.
> 
> I am sorry, but I simply do not see much point in this.  I think you meant
> by the title "non-commit upstream ref", as a tag that eventually peels to
> a commit is a committish.  Because a tag is meant to be immutable, forking

Ooops, of course you're right. I meant "not of type commit" but
resolvable to a commit, so in fact a non-commit committish.

> from that mean your further "merges from upstream" won't do anything, so
> the current behaviour of returning without saying anything sounds like the
> right thing to do, even though I strongly suspect that it behaves this way
> by accident not by design.

The current behavior is different: git branch/checkout allow you to
specify a tag as upstream, but error out and die when that info is used
(when stat_tracking_info() is called) with a mysterious message, saying
"A is a commit, not a tag", when in fact A is a tag (see Simon's report,
or try "git branch --track tmp v1.6.3-rc3" and run "git branch -v"),
because the entry in hash_obj is messed up.

So I claim that the current behavior is buggy, both on the user visible
side as well as in the internals (setting up wrong obj). The two
possible solutions are:

- Disallow non-commit upstreams. (But people can set anything using git
config.)
- Make stat_tracking_info() work with non-commit committish upstreams.

The latter is what my patch does, without changing behavior for commit
type upstreams.

> 
> Admittedly, I do not "fork and keep up-to-date with an upstream" that
> often, so I am in no way making a final decision here.  It would be
> healthy for interested people to discuss this patch, but I'd appreciate it
> if it happens after 1.6.3 final.

There is one huge advantage when your upstream is a tag: You may be
"ahead", but you'll never be "behind" ;)

Seriously, I find this useful as a way of developing topics on top of a
certain release and seeing the info in git branch -vv, git status etc.

In any case, erroring out and claiming that a tag is not a tag is a bug
which should be fixed one way or the other (which is why I thought it's
okay during rc, being a bug fix).

Michael