{"thread":{"id":"18433","subject":"Tracking of local branches","startedAt":"2009-03-20T14:22:38Z","lastAt":"2009-04-01T21:42:49Z","messageCount":15,"participants":["Michael J Gruber","Junio C Hamano","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"108719","messageId":"49C3A6AE.7020104@drmicha.warpmail.net","threadId":"18433","inReplyTo":null,"subject":"Tracking of local branches","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-03-20T14:22:38Z","receivedAt":"2009-03-20T14:22:38Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Hi there,\n\nme again. In connection with Dscho's recent patch which rang the bell on\ntracked branches I noticed that local branches are treated somewhat\ninconsistently by git. There are 2 ways to fix it, and I ask you for\nyour input on which one to choose.\n\nFirst of all:\nThe documentation seems to imply that it's okay to follow local\nbranches, i.e. to have tracked local branches. Specifically, the option\n--track allows setting up tracking info (branch.foo.merge) in cases\nwhere it's not set up automatically (it is when you branch off a remote\ntracking branch).\n\nIf it's not OK to say \"git checkout -b newbranch --track local\" when\nlocal is a local branch you can stop reading here and tell me to stop\nwriting...\n\nNow, assuming it's okay to have a local branch being tracked, the\ncurrent situation is:\n\ngit fetch/pull is okay (respects the setting)\ngit status/checkout/rev-parse BEL is not (acts as if there is no\ntracking info)\n\nI think I have tracked it down (pun intended) to the fact that one sort\nof commands looks at the struct member branch->merge, the other at\nbranch->merge_name. The latter is set for branches which follow\nsomething, the former only for followers of remote branches.\n\nI semi-successfully messed around in remote.c (format_tracking_info(),\nstat_tracking_info()) to make it use branch->merge_name rather than\nbranch->merge. This makes \"git status\" work as expected (\"Your branch\nis... severely screwed.\") for tracked local branches. (It's messed up\nfor remote ones but hey it was a first shot; merge[0]->dst is really\nneeded here I guess.)\n\nNow I could go after sha1_name.c and do the same,\n\nOR\n\nmake it so that all branches have their merge member set up, uhm. Any\npossible side effects?\n\nWhat do you think?\nMichael\n"},{"id":"108728","messageId":"49C3C0AF.6090806@drmicha.warpmail.net","threadId":"18433","inReplyTo":"49C3A6AE.7020104@drmicha.warpmail.net","subject":"Re: Tracking of local branches","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-03-20T16:13:35Z","receivedAt":"2009-03-20T16:13:35Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Michael J Gruber venit, vidit, dixit 20.03.2009 15:22:\n> Hi there,\n> \n> me again. In connection with Dscho's recent patch which rang the bell on\n> tracked branches I noticed that local branches are treated somewhat\n> inconsistently by git. There are 2 ways to fix it, and I ask you for\n> your input on which one to choose.\n> \n> First of all:\n> The documentation seems to imply that it's okay to follow local\n> branches, i.e. to have tracked local branches. Specifically, the option\n> --track allows setting up tracking info (branch.foo.merge) in cases\n> where it's not set up automatically (it is when you branch off a remote\n> tracking branch).\n> \n> If it's not OK to say \"git checkout -b newbranch --track local\" when\n> local is a local branch you can stop reading here and tell me to stop\n> writing...\n> \n> Now, assuming it's okay to have a local branch being tracked, the\n> current situation is:\n> \n> git fetch/pull is okay (respects the setting)\n> git status/checkout/rev-parse BEL is not (acts as if there is no\n> tracking info)\n> \n> I think I have tracked it down (pun intended) to the fact that one sort\n> of commands looks at the struct member branch->merge, the other at\n> branch->merge_name. The latter is set for branches which follow\n> something, the former only for followers of remote branches.\n> \n> I semi-successfully messed around in remote.c (format_tracking_info(),\n> stat_tracking_info()) to make it use branch->merge_name rather than\n> branch->merge. This makes \"git status\" work as expected (\"Your branch\n> is... severely screwed.\") for tracked local branches. (It's messed up\n> for remote ones but hey it was a first shot; merge[0]->dst is really\n> needed here I guess.)\n> \n> Now I could go after sha1_name.c and do the same,\n> \n> OR\n> \n> make it so that all branches have their merge member set up, uhm. Any\n> possible side effects?\n> \n> What do you think?\n> Michael\n\nOK, I think I got this working with approach 2 above. All existing tests\npass. Now I'll cook up tests which only my new code passes ;) But that\nmay take a few days.\n\nMichael\n"},{"id":"108733","messageId":"7viqm4i1md.fsf@gitster.siamese.dyndns.org","threadId":"18433","inReplyTo":"49C3A6AE.7020104@drmicha.warpmail.net","subject":"Re: Tracking of local branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-20T16:46:02Z","receivedAt":"2009-03-20T16:46:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> I semi-successfully messed around in remote.c (format_tracking_info(),\n> stat_tracking_info()) to make it use branch->merge_name rather than\n> branch->merge. This makes \"git status\" work as expected (\"Your branch\n> is... severely screwed.\") for tracked local branches. (It's messed up\n> for remote ones but hey it was a first shot; merge[0]->dst is really\n> needed here I guess.)\n>\n> Now I could go after sha1_name.c and do the same,\n>\n> OR\n>\n> make it so that all branches have their merge member set up, uhm. Any\n> possible side effects?\n\nMy gut feeling is that the latter if works should be preferable for\nconsistency if nothing else.\n\nThe \"struct branch\" hasn't changed ever since it was introduced by cf81834\n(Report information on branches from remote.h, 2007-09-10) and Daniel\nmight know about some corner cases that rely on branch.merge not being set\nup for local ones, but honestly, I would think it would be a bug in the\nexisting code if there were such cases.\n"},{"id":"108744","messageId":"alpine.LNX.1.00.0903201358440.19665@iabervon.org","threadId":"18433","inReplyTo":"7viqm4i1md.fsf@gitster.siamese.dyndns.org","subject":"Re: Tracking of local branches","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-03-20T18:10:46Z","receivedAt":"2009-03-20T18:10:46Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 20 Mar 2009, Junio C Hamano wrote:\n\n> Michael J Gruber writes:\n> \n> > I semi-successfully messed around in remote.c (format_tracking_info(),\n> > stat_tracking_info()) to make it use branch->merge_name rather than\n> > branch->merge. This makes \"git status\" work as expected (\"Your branch\n> > is... severely screwed.\") for tracked local branches. (It's messed up\n> > for remote ones but hey it was a first shot; merge[0]->dst is really\n> > needed here I guess.)\n> >\n> > Now I could go after sha1_name.c and do the same,\n> >\n> > OR\n> >\n> > make it so that all branches have their merge member set up, uhm. Any\n> > possible side effects?\n> \n> My gut feeling is that the latter if works should be preferable for\n> consistency if nothing else.\n> \n> The \"struct branch\" hasn't changed ever since it was introduced by cf81834\n> (Report information on branches from remote.h, 2007-09-10) and Daniel\n> might know about some corner cases that rely on branch.merge not being set\n> up for local ones, but honestly, I would think it would be a bug in the\n> existing code if there were such cases.\n\nAs long as the semantics for tracking local branches are the same as for \ntracking remote ones, I'm pretty sure there's nothing that relies on \nbranch.merge not being something local.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"109568","messageId":"1238100805-19619-1-git-send-email-git@drmicha.warpmail.net","threadId":"18433","inReplyTo":"alpine.LNX.1.00.0903201358440.19665@iabervon.org","subject":"[PATCH 0/2] Make local branches behave like remote branches when --tracked","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-03-26T20:53:23Z","receivedAt":"2009-03-26T20:53:23Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"[Sorry it took so long to finish... This is from my \"sick bed\", I hope\nit doesn't show ;)]\n\nThis mini series makes local branches behave the same as remote ones\nwhen they are used as --tracked branches. This means differences are\nreported by git status and git checkout, and also that the soon to be\nreleased tracking branch short cut (aka BEL) will work.\n\nMichael J Gruber (2):\n Test for local branches being followed with --track\n Make local branches behave like remote branches when --tracked\n\n remote.c | 9 +++++----\n t/t6040-tracking-info.sh | 10 +++++++++-\n 2 files changed, 14 insertions(+), 5 deletions(-)\n"},{"id":"109569","messageId":"1238100805-19619-2-git-send-email-git@drmicha.warpmail.net","threadId":"18433","inReplyTo":"1238100805-19619-1-git-send-email-git@drmicha.warpmail.net","subject":"[PATCH 1/2] Test for local branches being followed with --track","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-03-26T20:53:24Z","receivedAt":"2009-03-26T20:53:24Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"According to the documentation, it is perfectly okay to follow local\nbranches using the --track option. Introduce a test which checks whether\nthey behave the same. Currently 1 test fails.\n\nSigned-off-by: Michael J Gruber \n---\n t/t6040-tracking-info.sh | 10 +++++++++-\n 1 files changed, 9 insertions(+), 1 deletions(-)\n\ndiff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh\nindex ba90601..2a2b6b6 100755\n--- a/t/t6040-tracking-info.sh\n+++ b/t/t6040-tracking-info.sh\n@@ -29,7 +29,9 @@ test_expect_success setup '\n \t\tgit checkout -b b4 origin &&\n \t\tadvance e &&\n \t\tadvance f\n-\t)\n+\t) &&\n+\tgit checkout -b follower --track master &&\n+\tadvance g\n '\n \n script='s/^..\\(b.\\)[\t 0-9a-f]*\\[\\([^]]*\\)\\].*/\\1 \\2/p'\n@@ -56,6 +58,12 @@ test_expect_success 'checkout' '\n \tgrep \"have 1 and 1 different\" actual\n '\n \n+test_expect_failure 'checkout with local tracked branch' '\n+\tgit checkout master &&\n+\tgit checkout follower >actual\n+\tgrep \"is ahead of\" actual\n+'\n+\n test_expect_success 'status' '\n \t(\n \t\tcd test &&\n-- \n1.6.2.1.507.g0e68d\n"},{"id":"109570","messageId":"1238100805-19619-3-git-send-email-git@drmicha.warpmail.net","threadId":"18433","inReplyTo":"1238100805-19619-2-git-send-email-git@drmicha.warpmail.net","subject":"[PATCH 2/2] Make local branches behave like remote branches when --tracked","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-03-26T20:53:25Z","receivedAt":"2009-03-26T20:53:25Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"This makes sure that local branches, when followed using --track, behave\nthe same as remote ones (e.g. differences being reported by git status\nand git checkout). This fixes 1 known failure.\n\nSigned-off-by: Michael J Gruber \n---\n remote.c | 9 +++++----\n t/t6040-tracking-info.sh | 2 +-\n 2 files changed, 6 insertions(+), 5 deletions(-)\n\ndiff --git a/remote.c b/remote.c\nindex 2b037f1..5d2d7a1 100644\n--- a/remote.c\n+++ b/remote.c\n@@ -1170,8 +1170,9 @@ struct branch *branch_get(const char *name)\n \t\t\tfor (i = 0; i < ret->merge_nr; i++) {\n \t\t\t\tret->merge[i] = xcalloc(1, sizeof(**ret->merge));\n \t\t\t\tret->merge[i]->src = xstrdup(ret->merge_name[i]);\n-\t\t\t\tremote_find_tracking(ret->remote,\n-\t\t\t\t\t\t ret->merge[i]);\n+\t\t\t\tif(remote_find_tracking(ret->remote,\n+\t\t\t\t\t\t ret->merge[i]) && !strcmp(ret->remote_name, \".\"))\n+\t\t\t\t\tret->merge[i]->dst = xstrdup(ret->merge_name[i]);\n \t\t\t}\n \t\t}\n \t}\n@@ -1449,8 +1450,8 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb)\n \t\treturn 0;\n \n \tbase = branch->merge[0]->dst;\n-\tif (!prefixcmp(base, \"refs/remotes/\")) {\n-\t\tbase += strlen(\"refs/remotes/\");\n+\tif (!prefixcmp(base, \"refs/\")) {\n+\t\tbase += strlen(\"refs/\");\n \t}\n \tif (!num_theirs)\n \t\tstrbuf_addf(sb, \"Your branch is ahead of '%s' \"\ndiff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh\nindex 2a2b6b6..3d6db4d 100755\n--- a/t/t6040-tracking-info.sh\n+++ b/t/t6040-tracking-info.sh\n@@ -58,7 +58,7 @@ test_expect_success 'checkout' '\n \tgrep \"have 1 and 1 different\" actual\n '\n \n-test_expect_failure 'checkout with local tracked branch' '\n+test_expect_success 'checkout with local tracked branch' '\n \tgit checkout master &&\n \tgit checkout follower >actual\n \tgrep \"is ahead of\" actual\n-- \n1.6.2.1.507.g0e68d\n"},{"id":"109571","messageId":"49CBEC35.7030403@drmicha.warpmail.net","threadId":"18433","inReplyTo":"1238100805-19619-1-git-send-email-git@drmicha.warpmail.net","subject":"Re: [PATCH 0/2] Make local branches behave like remote branches when --tracked","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-03-26T20:57:25Z","receivedAt":"2009-03-26T20:57:25Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Michael J Gruber venit, vidit, dixit 26.03.2009 21:53:\n> [Sorry it took so long to finish... This is from my \"sick bed\", I hope\n> it doesn't show ;)]\n> \n> This mini series makes local branches behave the same as remote ones\n> when they are used as --tracked branches. This means differences are\n> reported by git status and git checkout, and also that the soon to be\n> released tracking branch short cut (aka BEL) will work.\n> \n> Michael J Gruber (2):\n> Test for local branches being followed with --track\n> Make local branches behave like remote branches when --tracked\n> \n> remote.c | 9 +++++----\n> t/t6040-tracking-info.sh | 10 +++++++++-\n> 2 files changed, 14 insertions(+), 5 deletions(-)\n> \n\nSorry, I meant to point out also that 2/2 changes the display format of\nthe branch: refs/ is removed rather than refs/remotes/, if present. This\nmakes for unique branch names ready to copy&paste (they were not\nnecessarily unique before).\n\nMichael\n"},{"id":"109622","messageId":"7vprg3fkw8.fsf@gitster.siamese.dyndns.org","threadId":"18433","inReplyTo":"1238100805-19619-3-git-send-email-git@drmicha.warpmail.net","subject":"Re: [PATCH 2/2] Make local branches behave like remote branches when --tracked","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-27T08:08:23Z","receivedAt":"2009-03-27T08:08:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> This makes sure that local branches, when followed using --track, behave\n> the same as remote ones (e.g. differences being reported by git status\n> and git checkout). This fixes 1 known failure.\n>\n> Signed-off-by: Michael J Gruber \n> ---\n> remote.c | 9 +++++----\n> t/t6040-tracking-info.sh | 2 +-\n> 2 files changed, 6 insertions(+), 5 deletions(-)\n>\n> diff --git a/remote.c b/remote.c\n> index 2b037f1..5d2d7a1 100644\n> --- a/remote.c\n> +++ b/remote.c\n> @@ -1170,8 +1170,9 @@ struct branch *branch_get(const char *name)\n> \t\t\tfor (i = 0; i < ret->merge_nr; i++) {\n> \t\t\t\tret->merge[i] = xcalloc(1, sizeof(**ret->merge));\n> \t\t\t\tret->merge[i]->src = xstrdup(ret->merge_name[i]);\n> -\t\t\t\tremote_find_tracking(ret->remote,\n> -\t\t\t\t\t\t ret->merge[i]);\n> +\t\t\t\tif(remote_find_tracking(ret->remote,\n> +\t\t\t\t\t\t ret->merge[i]) && !strcmp(ret->remote_name, \".\"))\n> +\t\t\t\t\tret->merge[i]->dst = xstrdup(ret->merge_name[i]);\n> \t\t\t}\n> \t\t}\n> \t}\n\nYuck; please have a SP betweeen \"if\" and \"(\", and also have a decency to\nbreak a long line at a more sensible place, like:\n\n\t\t\tif (remote_find_tracking(ret->remote, ret->merge[i])\n\t\t\t && !strcmp(...))\n \tthen do this;\n\nA naïve question from me to this change is why this \"fix-up\" is done here.\n\nThe remote_find_tracking() function is given a half-filled refspec (this\ncaller fills the src side, and asks to find the dst side to the function).\nAfter it fails to find a fetch refspec that copies remote refs to tracking\nrefs in the local repository that match the criteria, it returns -1 to\nsignal an error, otherwise it returns 0 after updating the other half of\nthe refspec.\n\nAfter calling r-f-t, because this new code assumes that for the \".\" remote\n(aka \"local repository\"), r-f-t lies and does not give back what it\nexpects, fixes what it got back from r-f-t. Shouldn't we be fixing this\ninside r-f-t?\n\n> @@ -1449,8 +1450,8 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb)\n> \t\treturn 0;\n> \n> \tbase = branch->merge[0]->dst;\n> -\tif (!prefixcmp(base, \"refs/remotes/\")) {\n> -\t\tbase += strlen(\"refs/remotes/\");\n> +\tif (!prefixcmp(base, \"refs/\")) {\n> +\t\tbase += strlen(\"refs/\");\n\nI am not sure if this is a good change. The majority of the case would\nbe remotes/ and we would be better off not repeating them. Can't you\nlimit the use of longer refs only when disambiguation is necessary?\n"},{"id":"109625","messageId":"49CC9285.407@drmicha.warpmail.net","threadId":"18433","inReplyTo":"7vprg3fkw8.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] Make local branches behave like remote branches when --tracked","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-03-27T08:47:01Z","receivedAt":"2009-03-27T08:47:01Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 27.03.2009 09:08:\n> Michael J Gruber writes:\n> \n>> This makes sure that local branches, when followed using --track, behave\n>> the same as remote ones (e.g. differences being reported by git status\n>> and git checkout). This fixes 1 known failure.\n>>\n>> Signed-off-by: Michael J Gruber \n>> ---\n>> remote.c | 9 +++++----\n>> t/t6040-tracking-info.sh | 2 +-\n>> 2 files changed, 6 insertions(+), 5 deletions(-)\n>>\n>> diff --git a/remote.c b/remote.c\n>> index 2b037f1..5d2d7a1 100644\n>> --- a/remote.c\n>> +++ b/remote.c\n>> @@ -1170,8 +1170,9 @@ struct branch *branch_get(const char *name)\n>> \t\t\tfor (i = 0; i < ret->merge_nr; i++) {\n>> \t\t\t\tret->merge[i] = xcalloc(1, sizeof(**ret->merge));\n>> \t\t\t\tret->merge[i]->src = xstrdup(ret->merge_name[i]);\n>> -\t\t\t\tremote_find_tracking(ret->remote,\n>> -\t\t\t\t\t\t ret->merge[i]);\n>> +\t\t\t\tif(remote_find_tracking(ret->remote,\n>> +\t\t\t\t\t\t ret->merge[i]) && !strcmp(ret->remote_name, \".\"))\n>> +\t\t\t\t\tret->merge[i]->dst = xstrdup(ret->merge_name[i]);\n>> \t\t\t}\n>> \t\t}\n>> \t}\n> \n> Yuck; please have a SP betweeen \"if\" and \"(\", and also have a decency to\n> break a long line at a more sensible place, like:\n> \n> \t\t\tif (remote_find_tracking(ret->remote, ret->merge[i])\n> \t\t\t && !strcmp(...))\n> \tthen do this;\n> \n\nSorry about the space. Regarding the break, you can see that the break\nwas like that before already, and I just followed suite, which I think\nmakes the diff more readable. But no problem changing that,\n\n> A naïve question from me to this change is why this \"fix-up\" is done here.\n\nIt was the easiest and least intrusive way for me...\n\n> \n> The remote_find_tracking() function is given a half-filled refspec (this\n> caller fills the src side, and asks to find the dst side to the function).\n> After it fails to find a fetch refspec that copies remote refs to tracking\n> refs in the local repository that match the criteria, it returns -1 to\n> signal an error, otherwise it returns 0 after updating the other half of\n> the refspec.\n> \n> After calling r-f-t, because this new code assumes that for the \".\" remote\n> (aka \"local repository\"), r-f-t lies and does not give back what it\n> expects, fixes what it got back from r-f-t. Shouldn't we be fixing this\n> inside r-f-t?\n\nThe technical reason is that there is no local remote, i.e. no remote\nstruct for '.', and I don't think we want it, because it would show up\nin all places where the list of remotes is searched/displayed/...\n\nWith ret being the branch we talk about, r-f-t is passed ret->remote and\nret->merge[i] only. In the local case, r-f-t cannot use the remote\nstruct for '.' (there is none) to find what it needs, and it has no easy\naccess to ret->merge_names[i] which is that info.\n\nbranch_get(), on the other hand, has all needed info in place. So,\nhaving r-f-t do it would require changing the parameters or adding a\nremote struct for '.' and adjusting all callers correspondingly. Doing\nit the way I did it is \"minimally invasive\" in that respect, with the\n(small) downside that we may call r-f-t unnecessarily in the local case\n- but we don't know before: If someone set up a remote config for '.'\nthen we have to go through r-f-t anayways.\n\n> \n>> @@ -1449,8 +1450,8 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb)\n>> \t\treturn 0;\n>> \n>> \tbase = branch->merge[0]->dst;\n>> -\tif (!prefixcmp(base, \"refs/remotes/\")) {\n>> -\t\tbase += strlen(\"refs/remotes/\");\n>> +\tif (!prefixcmp(base, \"refs/\")) {\n>> +\t\tbase += strlen(\"refs/\");\n> \n> I am not sure if this is a good change. The majority of the case would\n> be remotes/ and we would be better off not repeating them. Can't you\n> limit the use of longer refs only when disambiguation is necessary?\n> \n\nThe majority will be remotes, yes, but will the majority be unique? In\nmy case not. Even when we knew that format_tracking_info() would have\nto deal with remote branches only (before this series) there was a\n(high) chance of outputting non-unique refs, even worse: if foo is\nambiguous because refs/heads/foo and refs/remotes/foo exist then\nrefs/heads/foo would win, i.e. we used to output the *wrong* ref. The\nabove disambiguates. But I'll see if I can simplify the output based on\nthe necessity of disambiguation.\n\nMichael\n"},{"id":"109661","messageId":"7v1vsjey3s.fsf@gitster.siamese.dyndns.org","threadId":"18433","inReplyTo":"49CC9285.407@drmicha.warpmail.net","subject":"Re: [PATCH 2/2] Make local branches behave like remote branches when --tracked","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-27T16:20:39Z","receivedAt":"2009-03-27T16:20:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> Junio C Hamano venit, vidit, dixit 27.03.2009 09:08:\n> ...\n>> After calling r-f-t, because this new code assumes that for the \".\" remote\n>> (aka \"local repository\"), r-f-t lies and does not give back what it\n>> expects, fixes what it got back from r-f-t. Shouldn't we be fixing this\n>> inside r-f-t?\n>\n> The technical reason is that there is no local remote, i.e. no remote\n> struct for '.', and I don't think we want it, because it would show up\n> in all places where the list of remotes is searched/displayed/...\n>\n> With ret being the branch we talk about, r-f-t is passed ret->remote and\n> ret->merge[i] only. In the local case, r-f-t cannot use the remote\n> struct for '.' (there is none) to find what it needs, and it has no easy\n> access to ret->merge_names[i] which is that info.\n>\n> branch_get(), on the other hand, has all needed info in place.\n\nThanks for a detailed explanation. Would it deserve to be in the commit\nlog justification in a summarized form?\n\n> ..., even worse: if foo is\n> ambiguous because refs/heads/foo and refs/remotes/foo exist then\n> refs/heads/foo would win, i.e. we used to output the *wrong* ref. The\n> above disambiguates. But I'll see if I can simplify the output based on\n> the necessity of disambiguation.\n\nThanks.\n"},{"id":"109663","messageId":"49CD0440.6010304@drmicha.warpmail.net","threadId":"18433","inReplyTo":"7v1vsjey3s.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] Make local branches behave like remote branches when --tracked","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-03-27T16:52:16Z","receivedAt":"2009-03-27T16:52:16Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 27.03.2009 17:20:\n> Michael J Gruber writes:\n> \n>> Junio C Hamano venit, vidit, dixit 27.03.2009 09:08:\n>> ...\n>>> After calling r-f-t, because this new code assumes that for the \".\" remote\n>>> (aka \"local repository\"), r-f-t lies and does not give back what it\n>>> expects, fixes what it got back from r-f-t. Shouldn't we be fixing this\n>>> inside r-f-t?\n>>\n>> The technical reason is that there is no local remote, i.e. no remote\n>> struct for '.', and I don't think we want it, because it would show up\n>> in all places where the list of remotes is searched/displayed/...\n>>\n>> With ret being the branch we talk about, r-f-t is passed ret->remote and\n>> ret->merge[i] only. In the local case, r-f-t cannot use the remote\n>> struct for '.' (there is none) to find what it needs, and it has no easy\n>> access to ret->merge_names[i] which is that info.\n>>\n>> branch_get(), on the other hand, has all needed info in place.\n> \n> Thanks for a detailed explanation. Would it deserve to be in the commit\n> log justification in a summarized form?\n\nYou tell me :)\nI'm still unsure at times how detailed commit messages should be, but I\ntake it I should put a shortened version of the above in there.\n\n> \n>> ..., even worse: if foo is\n>> ambiguous because refs/heads/foo and refs/remotes/foo exist then\n>> refs/heads/foo would win, i.e. we used to output the *wrong* ref. The\n>> above disambiguates. But I'll see if I can simplify the output based on\n>> the necessity of disambiguation.\n> \n> Thanks.\n\nI thought about doing the following:\n- remove occurences of refs/remotes (like before the patch) and of\nrefs/heads. That way the output format stays the same, the amiguity\nproblem is not worsened\n- think later/harder about doing this more cleverly. I guess I need to\ncheck the output of dwim_ref, but have to figure out all the input\nparameters first...\n\nMichael\n"},{"id":"110169","messageId":"1238622169-5238-1-git-send-email-git@drmicha.warpmail.net","threadId":"18433","inReplyTo":"49CD0440.6010304@drmicha.warpmail.net","subject":"[PATCHv2 0/2] Make local branches behave like remote branches when --tracked","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-04-01T21:42:47Z","receivedAt":"2009-04-01T21:42:47Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"\nThis mini series makes local branches behave the same as remote ones\nwhen they are used as --tracked branches. This means differences are\nreported by git status and git checkout, and also that the soon to be\nreleased tracking branch short cut (aka BEL) will work.\n\nv2 adds a more detailed commit message to 2/2 and fixes up formatting.\nAlso, the simplification of remote refs is now unchanged, and local refs\nare simplified in the same way. This may lead to ambiguous refs just\nlike before this series. Unique simplification (which several places may\nbenefit from) is left for a future series.\n\nMichael J Gruber (2):\n Test for local branches being followed with --track\n Make local branches behave like remote branches when --tracked\n\n remote.c | 7 +++++--\n t/t6040-tracking-info.sh | 10 +++++++++-\n 2 files changed, 14 insertions(+), 3 deletions(-)\n"},{"id":"110168","messageId":"1238622169-5238-2-git-send-email-git@drmicha.warpmail.net","threadId":"18433","inReplyTo":"1238622169-5238-1-git-send-email-git@drmicha.warpmail.net","subject":"[PATCHv2 1/2] Test for local branches being followed with --track","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-04-01T21:42:48Z","receivedAt":"2009-04-01T21:42:48Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"According to the documentation, it is perfectly okay to follow local\nbranches using the --track option. Introduce a test which checks whether\nthey behave the same. Currently 1 test fails.\n\nSigned-off-by: Michael J Gruber \n---\n t/t6040-tracking-info.sh | 10 +++++++++-\n 1 files changed, 9 insertions(+), 1 deletions(-)\n\ndiff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh\nindex ba90601..2a2b6b6 100755\n--- a/t/t6040-tracking-info.sh\n+++ b/t/t6040-tracking-info.sh\n@@ -29,7 +29,9 @@ test_expect_success setup '\n \t\tgit checkout -b b4 origin &&\n \t\tadvance e &&\n \t\tadvance f\n-\t)\n+\t) &&\n+\tgit checkout -b follower --track master &&\n+\tadvance g\n '\n \n script='s/^..\\(b.\\)[\t 0-9a-f]*\\[\\([^]]*\\)\\].*/\\1 \\2/p'\n@@ -56,6 +58,12 @@ test_expect_success 'checkout' '\n \tgrep \"have 1 and 1 different\" actual\n '\n \n+test_expect_failure 'checkout with local tracked branch' '\n+\tgit checkout master &&\n+\tgit checkout follower >actual\n+\tgrep \"is ahead of\" actual\n+'\n+\n test_expect_success 'status' '\n \t(\n \t\tcd test &&\n-- \n1.6.2.1.507.g0e68d\n"},{"id":"110167","messageId":"1238622169-5238-3-git-send-email-git@drmicha.warpmail.net","threadId":"18433","inReplyTo":"1238622169-5238-2-git-send-email-git@drmicha.warpmail.net","subject":"[PATCHv2 2/2] Make local branches behave like remote branches when --tracked","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-04-01T21:42:49Z","receivedAt":"2009-04-01T21:42:49Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"This makes sure that local branches, when followed using --track, behave\nthe same as remote ones (e.g. differences being reported by git status\nand git checkout). This fixes 1 known failure.\n\nThe fix is done within branch_get(): The first natural candidate,\nnamely remote_find_tracking(), does not have all the necessary info\nbecause in general there is no remote struct for '.', and we don't want\none because it would show up in other places as well.\n\nbranch_get(), on the other hand, has access to merge_names[] (in\naddition to merge[]) and therefore can set up the followed branch\neasily.\n\nSigned-off-by: Michael J Gruber \n---\n remote.c | 7 +++++--\n t/t6040-tracking-info.sh | 2 +-\n 2 files changed, 6 insertions(+), 3 deletions(-)\n\ndiff --git a/remote.c b/remote.c\nindex 2b037f1..d12140e 100644\n--- a/remote.c\n+++ b/remote.c\n@@ -1170,8 +1170,9 @@ struct branch *branch_get(const char *name)\n \t\t\tfor (i = 0; i < ret->merge_nr; i++) {\n \t\t\t\tret->merge[i] = xcalloc(1, sizeof(**ret->merge));\n \t\t\t\tret->merge[i]->src = xstrdup(ret->merge_name[i]);\n-\t\t\t\tremote_find_tracking(ret->remote,\n-\t\t\t\t\t\t ret->merge[i]);\n+\t\t\t\tif (remote_find_tracking(ret->remote, ret->merge[i])\n+\t\t\t\t && !strcmp(ret->remote_name, \".\"))\n+\t\t\t\t\tret->merge[i]->dst = xstrdup(ret->merge_name[i]);\n \t\t\t}\n \t\t}\n \t}\n@@ -1451,6 +1452,8 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb)\n \tbase = branch->merge[0]->dst;\n \tif (!prefixcmp(base, \"refs/remotes/\")) {\n \t\tbase += strlen(\"refs/remotes/\");\n+\t} else if (!prefixcmp(base, \"refs/heads/\")) {\n+\t\tbase += strlen(\"refs/heads/\");\n \t}\n \tif (!num_theirs)\n \t\tstrbuf_addf(sb, \"Your branch is ahead of '%s' \"\ndiff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh\nindex 2a2b6b6..3d6db4d 100755\n--- a/t/t6040-tracking-info.sh\n+++ b/t/t6040-tracking-info.sh\n@@ -58,7 +58,7 @@ test_expect_success 'checkout' '\n \tgrep \"have 1 and 1 different\" actual\n '\n \n-test_expect_failure 'checkout with local tracked branch' '\n+test_expect_success 'checkout with local tracked branch' '\n \tgit checkout master &&\n \tgit checkout follower >actual\n \tgrep \"is ahead of\" actual\n-- \n1.6.2.1.507.g0e68d\n"}]}