{"thread":{"id":"19021","subject":"tracking branch on a tag","startedAt":"2009-04-23T09:52:52Z","lastAt":"2009-04-28T07:44:47Z","messageCount":4,"participants":["Simon Braunschmidt","Michael J Gruber","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"112074","messageId":"49F03A74.5080805@emlix.com","threadId":"19021","inReplyTo":null,"subject":"tracking branch on a tag","fromName":"Simon Braunschmidt","fromEmail":"sb@emlix.com","sentAt":"2009-04-23T09:52:52Z","receivedAt":"2009-04-23T09:52:52Z","isPatch":false,"sender":{"key":"sb@emlix.com","avatar":null},"body":"Hi\n\nSo i set up a tracking branch on an annotated signed tag like:\n\n\n$git branch --track foobranch v2.6.26\n >Branch foobranch set up to track local ref refs/tags/v2.6.26.\n\nCheck it out, get an error\n\n$git checkout foobranch\n >Switched to branch 'foobranch'\n >error: Object 14650d6ec137e70b6c1918cdef235027c5156020 is a commit, \nnot a tag\n >fatal: Invalid symmetric difference expression \nbce7f793daec3e65ec5c5705d2457b81fe7b5725...14650d6ec137e70b6c1918cdef235027c5156020\n\nInspect the relevant object\n\n$git-cat-file -p bce7f793daec3e65ec5c5705d2457b81fe7b5725\n >tree 05bc81f9b27a1ab60ea4e506357f0c7f2ece4eda\n >parent ec229e830060091b9be63c8f873c1b2407a82821\n >author Linus Torvalds 1215985889 -0700\n >committer Linus Torvalds 1215985889 -0700\n\n >Linux 2.6.26\n\n$git-cat-file -p 14650d6ec137e70b6c1918cdef235027c5156020\n >object bce7f793daec3e65ec5c5705d2457b81fe7b5725\n >type commit\n >tag v2.6.26\n >tagger Linus Torvalds Sun Jul 13 \n >14:51:38 2008 -0700\n >\n >Linux 2.6.26\n >-----BEGIN PGP SIGNATURE-----\n >Version: GnuPG v1.4.9 (GNU/Linux)\n >\n >iEYEABECAAYFAkh6ePIACgkQF3YsRnbiHLuJcACgpHzd21qAY25V2VQWBCYPW8bB\n >Z8MAoJ9qfiwuRt27cdrmAU2aJq+YFrYs\n >=aHK8\n >-----END PGP SIGNATURE-----\n\nI get this errors only on annotated/signed tags, not on lightweight \ntags. Admittedly it doesnt make much sense to track a tag, yet this \nerror message makes even less sense:\n\nerror: Object 14650d6ec137e70b6c1918cdef235027c5156020 is a commit, not \na tag\n\nwith 14650d being a tag.\n\nIs this error message serious, as fatal sound quite harsh? Can it be \navoided, by guiding the user on branch creation or by simply not \nshowing it in this situation?\n\nGruessle\nSimon\n"},{"id":"112432","messageId":"1240849603-26127-1-git-send-email-git@drmicha.warpmail.net","threadId":"19021","inReplyTo":"49F03A74.5080805@emlix.com","subject":"[PATCH] Fix behavior with non-committish upstream references","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-04-27T16:26:43Z","receivedAt":"2009-04-27T16:26:43Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"stat_tracking_info() assumes that upstream references (as specified by\n--track or set up automatically) are commits. By calling lookup_commit()\non them, create_objects() creates objects for them with type commit no\nmatter what their real type is; this disturbs lookup_tag() later on the\ncall sequence, leading to git status, git branch -v and git checkout\nerroring out.\n\nFix this by using lookup_commit_reference() instead so that (annotated)\ntags can be used as upstream references.\n\nSigned-off-by: Michael J Gruber \n---\nI'm sorry I won't be able to write a test any more today. Please let me\nwhether it's okay without a test.\n\n remote.c | 4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/remote.c b/remote.c\nindex d66e2f3..2c3e905 100644\n--- a/remote.c\n+++ b/remote.c\n@@ -1399,13 +1399,13 @@ int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)\n \tbase = branch->merge[0]->dst;\n \tif (!resolve_ref(base, sha1, 1, NULL))\n \t\treturn 0;\n-\ttheirs = lookup_commit(sha1);\n+\ttheirs = lookup_commit_reference(sha1);\n \tif (!theirs)\n \t\treturn 0;\n \n \tif (!resolve_ref(branch->refname, sha1, 1, NULL))\n \t\treturn 0;\n-\tours = lookup_commit(sha1);\n+\tours = lookup_commit_reference(sha1);\n \tif (!ours)\n \t\treturn 0;\n \n-- \n1.6.3.rc3\n"},{"id":"112496","messageId":"7vab61s0aq.fsf@gitster.siamese.dyndns.org","threadId":"19021","inReplyTo":"1240849603-26127-1-git-send-email-git@drmicha.warpmail.net","subject":"Re: [PATCH] Fix behavior with non-committish upstream references","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-04-28T07:30:05Z","receivedAt":"2009-04-28T07:30:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> stat_tracking_info() assumes that upstream references (as specified by\n> --track or set up automatically) are commits. By calling lookup_commit()\n> on them, create_objects() creates objects for them with type commit no\n> matter what their real type is; this disturbs lookup_tag() later on the\n> call sequence, leading to git status, git branch -v and git checkout\n> erroring out.\n>\n> Fix this by using lookup_commit_reference() instead so that (annotated)\n> tags can be used as upstream references.\n>\n> Signed-off-by: Michael J Gruber \n> ---\n> I'm sorry I won't be able to write a test any more today. Please let me\n> whether it's okay without a test.\n\nI am sorry, but I simply do not see much point in this. I think you meant\nby the title \"non-commit upstream ref\", as a tag that eventually peels to\na commit is a committish. Because a tag is meant to be immutable, forking\nfrom that mean your further \"merges from upstream\" won't do anything, so\nthe current behaviour of returning without saying anything sounds like the\nright thing to do, even though I strongly suspect that it behaves this way\nby accident not by design.\n\nAdmittedly, I do not \"fork and keep up-to-date with an upstream\" that\noften, so I am in no way making a final decision here. It would be\nhealthy for interested people to discuss this patch, but I'd appreciate it\nif it happens after 1.6.3 final.\n"},{"id":"112498","messageId":"49F6B3EF.8010503@drmicha.warpmail.net","threadId":"19021","inReplyTo":"7vab61s0aq.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Fix behavior with non-committish upstream references","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-04-28T07:44:47Z","receivedAt":"2009-04-28T07:44:47Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 28.04.2009 09:30:\n> Michael J Gruber writes:\n> \n>> stat_tracking_info() assumes that upstream references (as specified by\n>> --track or set up automatically) are commits. By calling lookup_commit()\n>> on them, create_objects() creates objects for them with type commit no\n>> matter what their real type is; this disturbs lookup_tag() later on the\n>> call sequence, leading to git status, git branch -v and git checkout\n>> erroring out.\n>>\n>> Fix this by using lookup_commit_reference() instead so that (annotated)\n>> tags can be used as upstream references.\n>>\n>> Signed-off-by: Michael J Gruber \n>> ---\n>> I'm sorry I won't be able to write a test any more today. Please let me\n>> whether it's okay without a test.\n> \n> I am sorry, but I simply do not see much point in this. I think you meant\n> by the title \"non-commit upstream ref\", as a tag that eventually peels to\n> a commit is a committish. Because a tag is meant to be immutable, forking\n\nOoops, of course you're right. I meant \"not of type commit\" but\nresolvable to a commit, so in fact a non-commit committish.\n\n> from that mean your further \"merges from upstream\" won't do anything, so\n> the current behaviour of returning without saying anything sounds like the\n> right thing to do, even though I strongly suspect that it behaves this way\n> by accident not by design.\n\nThe current behavior is different: git branch/checkout allow you to\nspecify a tag as upstream, but error out and die when that info is used\n(when stat_tracking_info() is called) with a mysterious message, saying\n\"A is a commit, not a tag\", when in fact A is a tag (see Simon's report,\nor try \"git branch --track tmp v1.6.3-rc3\" and run \"git branch -v\"),\nbecause the entry in hash_obj is messed up.\n\nSo I claim that the current behavior is buggy, both on the user visible\nside as well as in the internals (setting up wrong obj). The two\npossible solutions are:\n\n- Disallow non-commit upstreams. (But people can set anything using git\nconfig.)\n- Make stat_tracking_info() work with non-commit committish upstreams.\n\nThe latter is what my patch does, without changing behavior for commit\ntype upstreams.\n\n> \n> Admittedly, I do not \"fork and keep up-to-date with an upstream\" that\n> often, so I am in no way making a final decision here. It would be\n> healthy for interested people to discuss this patch, but I'd appreciate it\n> if it happens after 1.6.3 final.\n\nThere is one huge advantage when your upstream is a tag: You may be\n\"ahead\", but you'll never be \"behind\" ;)\n\nSeriously, I find this useful as a way of developing topics on top of a\ncertain release and seeing the info in git branch -vv, git status etc.\n\nIn any case, erroring out and claiming that a tag is not a tag is a bug\nwhich should be fixed one way or the other (which is why I thought it's\nokay during rc, being a bug fix).\n\nMichael\n"}]}