threads / discuss / 19021

tracking branch on a tag

Subject: tracking branch on a tag

## tl;dr

4 messages between Apr 23, 2009 and Apr 28, 2009.

replies: 3people: 3as markdown or json

Simon Braunschmidt· Apr 23, 2009, 09:52 UTC · lore

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

Michael J Gruber· Apr 27, 2009, 16:26 UTC · re: Simon Braunschmidt · lore

[PATCH] Fix behavior with non-committish upstream references

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

Junio C Hamano· Apr 28, 2009, 07:30 UTC · re: Michael J Gruber · lore

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

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

Show 14 quoted lines

> 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.

Michael J Gruber· Apr 28, 2009, 07:44 UTC · re: Junio C Hamano · lore

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

Junio C Hamano venit, vidit, dixit 28.04.2009 09:30:

Show 20 quoted lines

> 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.

Show 5 quoted lines

> 
> 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