{"thread":{"id":"6067","subject":"confusion over the new branch and merge config","startedAt":"2006-12-21T22:17:02Z","lastAt":"2007-01-09T16:18:32Z","messageCount":45,"participants":["Nicolas Pitre","Junio C Hamano","Sean","Alan Chandler","Andy Parkins","Lars Hjemli","Jakub Narebski","Tom Prince","Jeff King","Shawn Pearce","Johannes Schindelin","Santi Béjar"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"29972","messageId":"Pine.LNX.4.64.0612211555210.18171@xanadu.home","threadId":"6067","inReplyTo":null,"subject":"confusion over the new branch and merge config","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-21T22:17:02Z","receivedAt":"2006-12-21T22:17:02Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"\nOK I know I'm a total idiot and honnestly I didn't look at the code \nimplementation at all because I don't expect newbies to even look there. \n\nBut here's some pitfalls I'm sure people are likely to encounter...\n\n$ git clone git://git.kernel.org/pub/scm/git/git.git git\nInitialized empty Git repository in /home/nico/test/git/.git/\nremote: Generating pack...\nremote: Done counting 34527 objects.\nremote: Deltifying 34527 objects.\nremote: 100% (34527/34527) done\nIndexing 34527 objects.\nremote: Total 34527, written 34527 (delta 23920), reused 34111 (delta 23623)\n 100% (34527/34527) done\nResolving 23920 deltas.\n 100% (23920/23920) done\nChecking files out...\n 100% (748/748) done\n\n[ wooh! I feel good ]\n\n$ cd git\n$ git branch\n* master\n\n[ Hmmm... there used to be many more (remote) branches before. Where \n are they? Looking into .git/refs I see a remote/ directory and all \n remote branches are there. But I'm cheating now because a newbie \n might not even think of looking there.\n\n Ah? there is -a and -r options to git-branch. Fair enough. ]\n\n$ git branch -r\n* master\n origin/HEAD\n origin/html\n origin/maint\n origin/man\n origin/master\n origin/next\n origin/pu\n origin/todo\n$ git checkout next\nerror: pathspec 'next' did not match any file(s) known to git.\nDid you forget to 'git add'?\n\n[ WTF!?!? This definitely used to work before. OK it is listed as\n \"origin/next\" so let's try to be consistent. ]\n\n$ git checkout origin/next\ngit checkout: to checkout the requested commit you need to specify\n a name for a new branch which is created and switched to\n\n[ Hmmmmmmmm.... /me stares at the message wondering.\n I just want to _see_ and maybe _install_ the code from \"next\". ]\n\n$ git checkout origin/next local_next\nerror: pathspec 'local_next' did not match any file(s) known to git.\nDid you forget to 'git add'?\n\n[ But it just said to me above that I needed to provide a name for the \n branch to be switched to... Why doesn't it just work? F***ing tool!\n\n OK I'll use my git knowledge and cheat again. ]\n\n$ git checkout -b local_next origin/next\n\nThis is I think a good example where user experience might still be \nimproved. First the message about \"providing a name for a new branch\" \ncould certainly be less anbigous.\n\nThen the \"next\" branch name could possibly be made to work without the \n\"origin/\" if there is no conflict?\n\nAnd there was a discussion about allowing checkouts to be made from a \nremote branch but not allowing any commit on it. What happened of this \nidea?\n\nNow that I have my local_next branch, I want it to be kept up to date \nwhen performing a pull. Before the \"next\" branch sort of was always \nupdated, but now it is a separate thing I cannot see directly and I need \nto pull it in my local version.\n\n$ git pull origin/next\nfatal: The remote end hung up unexpectedly\nCannot get the repository state from git://git.kernel.org/pub/scm/git/git.git/next\n\n[ WTF? Where that ...pub/scm/git/git.git/next comes from? Hmmm... ]\n\n$ git pull next\nfatal: 'next': unable to chdir or not a git archive\nfatal: The remote end hung up unexpectedly\nCannot get the repository state from next\n\n[ ... an even more interesting set of error messages.\n\n Yeah, Linus says you must use git-pull . blah syntax. ]\n\n$ git pull . next\nerror: no such remote ref refs/heads/next\nFetch failure: .\n$ git pull . origin/next\nerror: no such remote ref refs/heads/origin/next\nFetch failure: .\n\n[ F**K YOU STUPID TOOL !!! OK let's cheat a bit again. ]\n\n$ git pull . remotes/origin/next\nAlready up-to-date.\n\n[ Woooh! But since I always hated this syntax let's try merge instead. ]\n\n$ git merge origin/next\nAlready up-to-date.\n\nOK here again various error messages could be improved. The fact that a \nremote connection was established in some cases is really dubious. And \ngit-pull not accepting \"origin/next\" is IMHO a bug.\n\nWell well... But I don't want to perform this two-step \ngit-pull+git-merge all the time. So let's have a look at this promising \nwarning:\n\n$ git pull origin\nWarning: No merge candidate found because value of config option\n \"branch.local_next.merge\" does not match any remote branch fetched.\nNo changes.\n\nSo this means that branch.local_next.merge should be set to origin/next? \nLet's have a look at the default in .git/config:\n\n[remote \"origin\"]\n url = git://git.kernel.org/pub/scm/git/git.git\n fetch = refs/heads/*:refs/remotes/origin/*\n[branch \"master\"]\n remote = origin\n merge = refs/heads/master\n\nBut according to the warning above, branch.master.merge should have been \nset to refs/remotes/origin/master, not refs/heads/master, right? \nOtherwise does this mean that master will merge itself into itself?\n\nThis is where my own git experience stops as I don't understand the \nabove for real. So let's see the doc:\n\n|branch..merge::\n| When in branch , it tells `git fetch` the default refspec to\n| be marked for merging in FETCH_HEAD. The value has exactly to match\n| a remote part of one of the refspecs which are fetched from the remote\n| given by \"branch..remote\".\n| The merge information is used by `git pull` (which at first calls\n| `git fetch`) to lookup the default branch for merging. Without\n| this option, `git pull` defaults to merge the first refspec fetched.\n| Specify multiple values to get an octopus merge.\n\nHmmmmmmm... Even after reading this twice I'm still not sure what it \nreally means. But as I said at the top I'm an idiot.\n\n\nNicolas\n"},{"id":"29973","messageId":"7vd56cam66.fsf@assigned-by-dhcp.cox.net","threadId":"6067","inReplyTo":"Pine.LNX.4.64.0612211555210.18171@xanadu.home","subject":"Re: confusion over the new branch and merge config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-21T23:01:21Z","receivedAt":"2006-12-21T23:01:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> [ Hmmm... there used to be many more (remote) branches before. Where \n> are they? Looking into .git/refs I see a remote/ directory and all \n> remote branches are there. But I'm cheating now because a newbie \n> might not even think of looking there.\n>\n> Ah? there is -a and -r options to git-branch. Fair enough. ]\n\nA newbie might not even expect to see \"many more branches\"\nbecause there is no \"before\" for him.\n\n> $ git checkout origin/next\n> git checkout: to checkout the requested commit you need to specify\n> a name for a new branch which is created and switched to\n>\n> [ Hmmmmmmmm.... /me stares at the message wondering.\n> I just want to _see_ and maybe _install_ the code from \"next\". ]\n\nRewording to suggest \"checkout -b newbranchname origin/next\", perhaps?\n\n> $ git checkout -b local_next origin/next\n\n\"git checkout -b next origin/next\" should work just fine, I\nthink.\n\nThere was a talk about allowing \"checkout -b \" to\nadd branch..merge and branch..remote if can be\nproven to corresond uniquely to one remote and one branch from\nthat remote; I think that would match the expectation most of\nthe time but that \"most\" would not be 100% nor even 80%, so I\nthink that should be an optional feature. In any case, there\nwas a talk but there is no code yet.\n\n> And there was a discussion about allowing checkouts to be made from a \n> remote branch but not allowing any commit on it. What happened of this \n> idea?\n\nIt remains to be an idle talk without any code. Contributions\nappreciated.\n\n> $ git pull origin/next\n> fatal: The remote end hung up unexpectedly\n> Cannot get the repository state from git://git.kernel.org/pub/scm/git/git.git/next\n>\n> [ WTF? Where that ...pub/scm/git/git.git/next comes from? Hmmm... ]\n\nThis comes from ancient request by Linus to allow:\n\n\t$ cat .git/remotes/jgarzik\n\tURL: master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/\n\t$ git pull jgarzik/misc-2.6\n\nSee http://article.gmane.org/gmane.comp.version-control.git/6181\nfor the full text.\n\nPersonally I thought this was confusing when I implemented it\nthe first time, and I still find it confusing.\n\nI suspect nobody uses it. I am all for removing this \"URL\nprefix shorthand\" feature in v1.5.0.\n\n> $ git pull . remotes/origin/next\n> Already up-to-date.\n>\n> [ Woooh! But since I always hated this syntax let's try merge instead. ]\n>\n> $ git merge origin/next\n> Already up-to-date.\n\nYes, that is one of the reasons that you would prefer 'merge'\nwhen you are working locally.\n\n> $ git pull origin\n> Warning: No merge candidate found because value of config option\n> \"branch.local_next.merge\" does not match any remote branch fetched.\n> No changes.\n>\n> So this means that branch.local_next.merge should be set to origin/next? \n\nNo, the message says \"any REMOTE branch\" -- refs/heads/next is\nwhat it is called at the remote, and that is how the value is\nexpected to be spelled; I think somebody added an example to\nconfig.txt recently to stress this. The above error messasge\nobviously was not clear enough. Rewording appreciated.\n"},{"id":"29974","messageId":"20061221182102.906ad046.seanlkml@sympatico.ca","threadId":"6067","inReplyTo":"7vd56cam66.fsf@assigned-by-dhcp.cox.net","subject":"Re: confusion over the new branch and merge config","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-12-21T23:21:02Z","receivedAt":"2006-12-21T23:21:02Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, 21 Dec 2006 15:01:21 -0800\nJunio C Hamano wrote:\n\n> No, the message says \"any REMOTE branch\" -- refs/heads/next is\n> what it is called at the remote, and that is how the value is\n> expected to be spelled; I think somebody added an example to\n> config.txt recently to stress this. The above error messasge\n> obviously was not clear enough. Rewording appreciated.\n\nThis seems inconsistent and confusing. When working with the\nlocal repository, git-branch doesn't list that as \"refs/heads/next\"\nit just lists \"next\". Why all of a sudden when trying to fetch\nit from a remote repo must a user know about \"refs/heads\"?\n\nThis seems like an internal detail slipping into the user interface.\nBut maybe i'm wrong, when would it ever be anything other than\n\"refs/heads/\"? If it's _always_ \"refs/heads\", couldn't that\nprefix just be assumed if not provided by the user?\n\nSean\n"},{"id":"29978","messageId":"7vzm9g932b.fsf@assigned-by-dhcp.cox.net","threadId":"6067","inReplyTo":"20061221182102.906ad046.seanlkml@sympatico.ca","subject":"Re: confusion over the new branch and merge config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-22T00:39:24Z","receivedAt":"2006-12-22T00:39:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sean writes the value of\nbranch..merge being the name at the remote site, saying:\n\n> This seems inconsistent and confusing.\n\nCheck the archive for messages on this issue that talks about\nthe case without tracking branches.\n"},{"id":"29980","messageId":"7vvek492q1.fsf@assigned-by-dhcp.cox.net","threadId":"6067","inReplyTo":"20061221182102.906ad046.seanlkml@sympatico.ca","subject":"Re: confusion over the new branch and merge config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-22T00:46:46Z","receivedAt":"2006-12-22T00:46:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sean writes:\n\n> This seems inconsistent and confusing. When working with the\n> local repository, git-branch doesn't list that as \"refs/heads/next\"\n> it just lists \"next\". Why all of a sudden when trying to fetch\n> it from a remote repo must a user know about \"refs/heads\"?\n\nYou can always say \"git log refs/heads/next\" even though you are\nallowed to say \"git log next\". Maybe we should remove that\nshorthand to make it consistent? I think not.\n\nThe remote side can add things without your knowing, so\ninsisting on the exact match makes sense in a weird sort of\nway.\n\nAnd this is a config file you would set once and then can forget\nabout it. I do not see a big deal about having to spell it\nfully.\n"},{"id":"29991","messageId":"20061221200148.ac6e39b4.seanlkml@sympatico.ca","threadId":"6067","inReplyTo":"7vvek492q1.fsf@assigned-by-dhcp.cox.net","subject":"Re: confusion over the new branch and merge config","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-12-22T01:01:48Z","receivedAt":"2006-12-22T01:01:48Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, 21 Dec 2006 16:46:46 -0800\nJunio C Hamano wrote:\n\n> You can always say \"git log refs/heads/next\" even though you are\n> allowed to say \"git log next\". Maybe we should remove that\n> shorthand to make it consistent? I think not.\n\nOf course not. But why not add the shorthand to the other case\nto make it consistent?\n\n> The remote side can add things without your knowing, so\n> insisting on the exact match makes sense in a weird sort of\n> way.\n\nI'm sure there are technical reasons why things are they way they\nare, nothing weird about that. But looking in from the outside\nand not knowing what those reasons are, leads to an honest\nquestion if it's absolutely necessary for a user to have to learn\nabout the internal \"refs/heads\" directory structure of Git.\nIt would be nicer if they could just think in terms of branches\nand tags.\n \n> And this is a config file you would set once and then can forget\n> about it. I do not see a big deal about having to spell it\n> fully.\n\nIt's not a huge deal, it's just one more slightly unexpected thing\nfor a user to have to deal with in learning Git. It seems reasonable\nfor a user to be able to refer to a remote branch as \"remote/branch\",\nand not \"remote/refs/heads/branch\". But if that simply can't be\naccommodated, so be it.\n\nSean\n"},{"id":"30019","messageId":"200612220750.49644.alan@chandlerfamily.org.uk","threadId":"6067","inReplyTo":"7vd56cam66.fsf@assigned-by-dhcp.cox.net","subject":"Re: confusion over the new branch and merge config","fromName":"Alan Chandler","fromEmail":"alan@chandlerfamily.org.uk","sentAt":"2006-12-22T07:50:49Z","receivedAt":"2006-12-22T07:50:49Z","isPatch":false,"sender":{"key":"alan@chandlerfamily.org.uk","avatar":"https://gravatar.com/avatar/1862247e5ea8eac114c842f9dc3a5db6253754e24ef7171757cf97eedce48b8c?d=mp&s=160"},"body":"On Thursday 21 December 2006 23:01, Junio C Hamano wrote:\n> Nicolas Pitre writes:\n> > [ Hmmm... there used to be many more (remote) branches before. \n> > Where are they? Looking into .git/refs I see a remote/ directory\n> > and all remote branches are there. But I'm cheating now because a\n> > newbie might not even think of looking there.\n> >\n> > Ah? there is -a and -r options to git-branch. Fair enough. ]\n\nAdded snipped content back in\n>>\n>> $ git branch -r\n>> * master\n>> origin/HEAD\n>> origin/html\n>> origin/maint\n>> origin/man\n>> origin/master\n>> origin/next\n>> origin/pu\n>> origin/todo\n\nAnd according to the man page git branch -r should print ONLY the remote \nbranches\n\n>\n> A newbie might not even expect to see \"many more branches\"\n> because there is no \"before\" for him.\n\n>\n> > $ git checkout origin/next\n> > git checkout: to checkout the requested commit you need to specify\n> > a name for a new branch which is created and switched\n\nWhat about the error message saying that origin/next is read only. \nSomething like\n\ngit-checkout: the requested commit is on a remote read only branch. You \nneed to specify a new local branch with the -b option to proceed.\n\n> > to\n> >\n> > [ Hmmmmmmmm.... /me stares at the message wondering.\n> > I just want to _see_ and maybe _install_ the code from \"next\". ]\n>\n> Rewording to suggest \"checkout -b newbranchname origin/next\",\n> perhaps?\n>\n> > $ git checkout -b local_next origin/next\n>\n> \"git checkout -b next origin/next\" should work just fine, I\n> think.\n>\n\n-- \nAlan Chandler\nhttp://www.chandlerfamily.org.uk\n"},{"id":"30023","messageId":"7vfyb85ojf.fsf@assigned-by-dhcp.cox.net","threadId":"6067","inReplyTo":"200612220750.49644.alan@chandlerfamily.org.uk","subject":"Re: confusion over the new branch and merge config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-22T08:21:24Z","receivedAt":"2006-12-22T08:21:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alan Chandler writes:\n\n> And according to the man page git branch -r should print ONLY the remote \n> branches\n\nHeh, sounds like you spotted a bug -- patches welcome (or I'll\nfix it myself if I get around to it before everybody else).\nThanks.\n\n>> > $ git checkout origin/next\n>> > git checkout: to checkout the requested commit you need to specify\n>> > a name for a new branch which is created and switched\n>\n> What about the error message saying that origin/next is read only. \n> Something like\n>\n> git-checkout: the requested commit is on a remote read only branch. You \n> need to specify a new local branch with the -b option to proceed.\n\nI agree that explicitly suggesting the use of -b is a good idea,\nbut your wording is a bit too specific; after all you might do\n\n\t$ H=`git-rev-parse origin/next`\n $ git checkout $H\n\nand there is not enough information to say \"is on a remote read\nonly branch\". We could do that with more specific hacks in\ngit-checkout; patches welcome.\n"},{"id":"30027","messageId":"200612220831.26497.andyparkins@gmail.com","threadId":"6067","inReplyTo":"7vvek492q1.fsf@assigned-by-dhcp.cox.net","subject":"Re: confusion over the new branch and merge config","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-22T08:31:25Z","receivedAt":"2006-12-22T08:31:25Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2006 December 22 00:46, Junio C Hamano wrote:\n\n> You can always say \"git log refs/heads/next\" even though you are\n> allowed to say \"git log next\". Maybe we should remove that\n> shorthand to make it consistent? I think not.\n\nOn a related subject - I'd like to remove all the \"refs/\" literals from git. \nAll refs are always under \"refs/\", so prefixing everything with refs/ is just \nnoise.\n\nThe place that makes it stand out that this is wrong is (I think) found in \nrefs.c (excuse my abuse of syntax):\n\nint for_each_ref(each_ref_fn fn, void *cb_data)\n return do_for_each_ref(\"refs/\", fn, 0, cb_data);\nint for_each_tag_ref(each_ref_fn fn, void *cb_data)\n return do_for_each_ref(\"refs/tags/\", fn, 10, cb_data);\nint for_each_branch_ref(each_ref_fn fn, void *cb_data)\n return do_for_each_ref(\"refs/heads/\", fn, 11, cb_data);\nint for_each_remote_ref(each_ref_fn fn, void *cb_data)\n return do_for_each_ref(\"refs/remotes/\", fn, 13, cb_data);\n\nWhat's significant is that it is only for_each_ref() that hands the prefix \nback. The change I'd like to make is \n return do_for_each_ref(\"refs/\", fn, 5, cb_data);\n\nObviously, this will imply a lot of changes everywhere else; so I didn't want \nto dive into it without mentioning it here first.\n\nIs this a sensible thing to want to do? \n\nAs I'm talking about code cleanups, I'd also like to change all variables \ncalled \"sha1\" to \"hash\" (or similar). The point being that the variables \nhold hashes not sha1's.\n\nI don't say that the above are serious problems, I just like cleaning code :-)\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"30030","messageId":"200612220839.36067.andyparkins@gmail.com","threadId":"6067","inReplyTo":"7vfyb85ojf.fsf@assigned-by-dhcp.cox.net","subject":"Re: confusion over the new branch and merge config","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-22T08:39:33Z","receivedAt":"2006-12-22T08:39:33Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2006 December 22 08:21, Junio C Hamano wrote:\n\n> Heh, sounds like you spotted a bug -- patches welcome (or I'll\n> fix it myself if I get around to it before everybody else).\n> Thanks.\n\nI can't reproduce this bug. I tried having an identically named branch in \nboth remotes and heads. Output was fine. I don't like to say \"impossible\", \nbut it certainly seems that\n\nThis from append_ref():\n } else if (!strncmp(refname, \"refs/remotes/\", 13)) {\n kind = REF_REMOTE_BRANCH;\n\nand this from print_ref_list():\n if (ref_list.list[i].kind == REF_LOCAL_BRANCH &&\n !strcmp(ref_list.list[i].name, head)) {\n c = '*';\n\nMake it almost inconceivable that a remote branch is being starred, or that a \nlocal branch is making it into the \"-r\" output.\n\nAlan: could you show a tree of your .git/refs/heads and your .git/refs/remotes \nfor the repository that is displaying this error?\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"30031","messageId":"200612220841.46016.andyparkins@gmail.com","threadId":"6067","inReplyTo":"Pine.LNX.4.64.0612211555210.18171@xanadu.home","subject":"Re: confusion over the new branch and merge config","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-22T08:41:44Z","receivedAt":"2006-12-22T08:41:44Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2006 December 21 22:17, Nicolas Pitre wrote:\n\nSorry Alan; I thought it was your bug - it wasn't...\n\n> $ git branch -r\n> * master\n> origin/HEAD\n> origin/html\n> origin/maint\n> origin/man\n> origin/master\n> origin/next\n> origin/pu\n> origin/todo\n\nI'm trying to track down why \"master\" is being shown in this case\"; would it \nbe possible to show me the output of\n\n$ tree .git/refs/heads .git/refs/remotes\n\nAs I am having trouble reproducing this error.\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"30038","messageId":"8c5c35580612220139x491dc3ecwf3fc60dda2fa379f@mail.gmail.com","threadId":"6067","inReplyTo":"200612220841.46016.andyparkins@gmail.com","subject":"Re: confusion over the new branch and merge config","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2006-12-22T09:39:30Z","receivedAt":"2006-12-22T09:39:30Z","isPatch":false,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 12/22/06, Andy Parkins wrote:\n> On Thursday 2006 December 21 22:17, Nicolas Pitre wrote:\n> > $ git branch -r\n> > * master\n> > origin/HEAD\n> > origin/html\n> > origin/maint\n> > origin/man\n> > origin/master\n> > origin/next\n> > origin/pu\n> > origin/todo\n>\n> I'm trying to track down why \"master\" is being shown in this case\";\n\nThis looks very much like \"git branch -a\".\n\nI've just tried this:\n\n$ git clone git://git2.kernel.org/pub/scm/git/git.git\nInitialized empty Git repository in /home/larsh/src/tmp/git/.git/\nremote: Generating pack...\nremote: Done counting 34527 objects.\nremote: Deltifying 34527 objects.\nremote: 100% (34527/34527) done\nIndexing 34527 objects.\nremote: Total 34527, written 34527 (delta 23920), reused 34111 (delta 23623)\n 100% (34527/34527) done\nResolving 23920 deltas.\n 100% (23920/23920) done\nChecking files out...\n 100% (748/748) done\n$ cd git\n$ git branch -r\n origin/HEAD\n origin/html\n origin/maint\n origin/man\n origin/master\n origin/next\n origin/pu\n origin/todo\n$ git branch -a\n* master\n origin/HEAD\n origin/html\n origin/maint\n origin/man\n origin/master\n origin/next\n origin/pu\n origin/todo\n$ cp .git/refs/heads/master .git/refs/remotes/master\n$ git branch -r\n master\n origin/HEAD\n origin/html\n origin/maint\n origin/man\n origin/master\n origin/next\n origin/pu\n origin/todo\n$ git symbolic-ref HEAD refs/remotes/master\n$ git branch -r\nfatal: HEAD not found below refs/heads!\n$ git --version\ngit version 1.4.4.2.gee60\n\n\n-- \nlarsh\n"},{"id":"30061","messageId":"Pine.LNX.4.64.0612221009310.18171@xanadu.home","threadId":"6067","inReplyTo":"8c5c35580612220139x491dc3ecwf3fc60dda2fa379f@mail.gmail.com","subject":"Re: confusion over the new branch and merge config","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-22T15:10:13Z","receivedAt":"2006-12-22T15:10:13Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 22 Dec 2006, Lars Hjemli wrote:\n\n> On 12/22/06, Andy Parkins wrote:\n> > On Thursday 2006 December 21 22:17, Nicolas Pitre wrote:\n> > > $ git branch -r\n> > > * master\n> > > origin/HEAD\n> > > origin/html\n> > > origin/maint\n> > > origin/man\n> > > origin/master\n> > > origin/next\n> > > origin/pu\n> > > origin/todo\n> >\n> > I'm trying to track down why \"master\" is being shown in this case\";\n> \n> This looks very much like \"git branch -a\".\n\nYes it was. I just pasted the wrong line in my example. Sorry.\n\n\nNicolas\n"},{"id":"30063","messageId":"200612221525.46132.alan@chandlerfamily.org.uk","threadId":"6067","inReplyTo":"200612220839.36067.andyparkins@gmail.com","subject":"Re: confusion over the new branch and merge config","fromName":"Alan Chandler","fromEmail":"alan@chandlerfamily.org.uk","sentAt":"2006-12-22T15:25:45Z","receivedAt":"2006-12-22T15:25:45Z","isPatch":false,"sender":{"key":"alan@chandlerfamily.org.uk","avatar":"https://gravatar.com/avatar/1862247e5ea8eac114c842f9dc3a5db6253754e24ef7171757cf97eedce48b8c?d=mp&s=160"},"body":"On Friday 22 December 2006 08:39, Andy Parkins wrote:\n\n> Make it almost inconceivable that a remote branch is being starred,\n> or that a local branch is making it into the \"-r\" output.\n>\n> Alan: could you show a tree of your .git/refs/heads and your\n> .git/refs/remotes for the repository that is displaying this error?\n\nIt wasn't my repository I was responding to - it was Nicolas Pitre's \npost that listed both remote and local branches - and I then looked at \nthe man page to see what -r did and saw that it said \"only\" remote \nbranches.\n\n-- \nAlan Chandler\nhttp://www.chandlerfamily.org.uk\n"},{"id":"30097","messageId":"Pine.LNX.4.64.0612221539100.18171@xanadu.home","threadId":"6067","inReplyTo":"7vd56cam66.fsf@assigned-by-dhcp.cox.net","subject":"Re: confusion over the new branch and merge config","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-22T20:49:46Z","receivedAt":"2006-12-22T20:49:46Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 21 Dec 2006, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > $ git pull origin/next\n> > fatal: The remote end hung up unexpectedly\n> > Cannot get the repository state from git://git.kernel.org/pub/scm/git/git.git/next\n> >\n> > [ WTF? Where that ...pub/scm/git/git.git/next comes from? Hmmm... ]\n> \n> This comes from ancient request by Linus to allow:\n> \n> \t$ cat .git/remotes/jgarzik\n> \tURL: master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/\n> \t$ git pull jgarzik/misc-2.6\n> \n> See http://article.gmane.org/gmane.comp.version-control.git/6181\n> for the full text.\n> \n> Personally I thought this was confusing when I implemented it\n> the first time, and I still find it confusing.\n> \n> I suspect nobody uses it. I am all for removing this \"URL\n> prefix shorthand\" feature in v1.5.0.\n\nPlease do. I'm sure Linus can find a better way now.\n\n> > $ git pull . remotes/origin/next\n> > Already up-to-date.\n> >\n> > [ Woooh! But since I always hated this syntax let's try merge instead. ]\n> >\n> > $ git merge origin/next\n> > Already up-to-date.\n> \n> Yes, that is one of the reasons that you would prefer 'merge'\n> when you are working locally.\n\nSure. But why doesn't pull accept \"origin/next\"?\n\n> > $ git pull origin\n> > Warning: No merge candidate found because value of config option\n> > \"branch.local_next.merge\" does not match any remote branch fetched.\n> > No changes.\n> >\n> > So this means that branch.local_next.merge should be set to origin/next? \n> \n> No, the message says \"any REMOTE branch\" -- refs/heads/next is\n> what it is called at the remote, and that is how the value is\n> expected to be spelled; I think somebody added an example to\n> config.txt recently to stress this. The above error messasge\n> obviously was not clear enough. Rewording appreciated.\n\nBut wouldn't it be much less confusing if it used the local name for \nthat remote branch instead? After all it is what should be used with \ngit-merge if performed manually, it is what diff, log, and al must use \nas well. Why would this need a remote name for something that is a \nlocal operation after all? I think \"refs/heads/master\" is really \nambigous since you might be confused between the local and remote \nmeaning of it, whereas \"origin/master\" carries no confusion at all.\n\n\nNicolas\n"},{"id":"30099","messageId":"emhh4k$u4q$1@sea.gmane.org","threadId":"6067","inReplyTo":"Pine.LNX.4.64.0612221539100.18171@xanadu.home","subject":"Re: confusion over the new branch and merge config","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-22T21:04:57Z","receivedAt":"2006-12-22T21:04:57Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\n\nNicolas Pitre wrote:\n> On Thu, 21 Dec 2006, Junio C Hamano wrote:\n\n>> No, the message says \"any REMOTE branch\" -- refs/heads/next is\n>> what it is called at the remote, and that is how the value is\n>> expected to be spelled; I think somebody added an example to\n>> config.txt recently to stress this.  The above error messasge\n>> obviously was not clear enough.  Rewording appreciated.\n> \n> But wouldn't it be much less confusing if it used the local name for \n> that remote branch instead?  After all it is what should be used with \n> git-merge if performed manually, it is what diff, log, and al must use \n> as well.  Why would this need a remote name for something that is a \n> local operation after all?  I think \"refs/heads/master\" is really \n> ambigous since you might be confused between the local and remote \n> meaning of it, whereas \"origin/master\" carries no confusion at all.\n\nPerhaps less confusing, but also less powerfull. Current notation\nallows for pulling _without need for tracking branches_.\n\nAlthough I wonder if it is possible to have multiple branch..remote,\nand branch..merge always refering to latest remote (octopus if there\nare more than one branch..merge for remote)...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"30104","messageId":"Pine.LNX.4.64.0612221609430.18171@xanadu.home","threadId":"6067","inReplyTo":"emhh4k$u4q$1@sea.gmane.org","subject":"Re: confusion over the new branch and merge config","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-22T21:20:31Z","receivedAt":"2006-12-22T21:20:31Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"\nCould you at least keep me in CC when replying to me please?\n\nOn Fri, 22 Dec 2006, Jakub Narebski wrote:\n\n> \n\n?\n\n> Nicolas Pitre wrote:\n> > On Thu, 21 Dec 2006, Junio C Hamano wrote:\n> \n> >> No, the message says \"any REMOTE branch\" -- refs/heads/next is\n> >> what it is called at the remote, and that is how the value is\n> >> expected to be spelled; I think somebody added an example to\n> >> config.txt recently to stress this.  The above error messasge\n> >> obviously was not clear enough.  Rewording appreciated.\n> > \n> > But wouldn't it be much less confusing if it used the local name for \n> > that remote branch instead?  After all it is what should be used with \n> > git-merge if performed manually, it is what diff, log, and al must use \n> > as well.  Why would this need a remote name for something that is a \n> > local operation after all?  I think \"refs/heads/master\" is really \n> > ambigous since you might be confused between the local and remote \n> > meaning of it, whereas \"origin/master\" carries no confusion at all.\n> \n> Perhaps less confusing, but also less powerfull. Current notation\n> allows for pulling _without need for tracking branches_.\n\nIs this really a killer feature worth the confusion?\n\nIf you put the repo to pull from on the command line then sure you might \nnot want a tracking branch, but if you go to the trouble of adding a \nbranch.blah.merge config entry then you certainly don't mind having a \ntracking branch?\n\n\nNicolas\n"},{"id":"30122","messageId":"200612222340.50029.jnareb@gmail.com","threadId":"6067","inReplyTo":"Pine.LNX.4.64.0612221609430.18171@xanadu.home","subject":"Re: confusion over the new branch and merge config","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-22T22:40:49Z","receivedAt":"2006-12-22T22:40:49Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nicolas Pitre wrote:\n> \n> Could you at least keep me in CC when replying to me please?\n\nI have Cc-ed you and Junio, but somehow message I send to mailing\nlist loses the Cc:. Perhaps it is time to change news client (KMail),\nor upgrade it...\n\n> On Fri, 22 Dec 2006, Jakub Narebski wrote:\n> \n>> \n> \n> ?\n\nSorry, it is added (in my locale) when both sending reply via mail,\nand to newsgroup (and to git mailing list via GMane NNTP news2mail\ninterface).\n\n\n>> Perhaps less confusing, but also less powerfull. Current notation\n>> allows for pulling _without need for tracking branches_.\n> \n> Is this really a killer feature worth the confusion?\n> \n> If you put the repo to pull from on the command line then sure you might \n> not want a tracking branch, but if you go to the trouble of adding a \n> branch.blah.merge config entry then you certainly don't mind having a \n> tracking branch?\n\nI'm not sure. On one hand you have this feature, pulling without tracking\nbranch (which is nice workflow for one-branch repos at least), on the\nother hand the tracking branch tells us the remote, and we can check if\nthey match. \n\nOn another hand, you can have two remotes which are the same repository\n(mirrors for example)... although that would be better solved by allowing\nmultiple url...\n-- \nJakub Narebski\nPoland\n"},{"id":"30128","messageId":"7vpsabv6tm.fsf@assigned-by-dhcp.cox.net","threadId":"6067","inReplyTo":"Pine.LNX.4.64.0612221539100.18171@xanadu.home","subject":"Re: confusion over the new branch and merge config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-22T23:39:33Z","receivedAt":"2006-12-22T23:39:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Thu, 21 Dec 2006, Junio C Hamano wrote:\n>\n>> Nicolas Pitre writes:\n>> \n>> > $ git pull origin/next\n>> > fatal: The remote end hung up unexpectedly\n>> > Cannot get the repository state from git://git.kernel.org/pub/scm/git/git.git/next\n>> >\n>> > [ WTF? Where that ...pub/scm/git/git.git/next comes from? Hmmm... ]\n>> \n>> This comes from ancient request by Linus to allow:\n>> \n>> \t$ cat .git/remotes/jgarzik\n>> \tURL: master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/\n>> \t$ git pull jgarzik/misc-2.6\n>> \n>> See http://article.gmane.org/gmane.comp.version-control.git/6181\n>> for the full text.\n>> \n>> Personally I thought this was confusing when I implemented it\n>> the first time, and I still find it confusing.\n>> \n>> I suspect nobody uses it. I am all for removing this \"URL\n>> prefix shorthand\" feature in v1.5.0.\n>\n> Please do. I'm sure Linus can find a better way now.\n\nWell, \"request\" was very inprecise word -- I should have said\n\"suggestion\". But I think I agree.\n\nSeconds? Thirds?\n\n-- >8 --\n[PATCH] Do not support \"partial URL shorthand\" anymore.\n\nWe used to support specifying the top part of remote URL in\nremotes and use that as a short-hand for the URL.\n\n\t$ cat .git/remotes/jgarzik\n\tURL: git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/\n\t$ git pull jgarzik/misc-2.6\n\nThis is confusing when somebody attempts to do this:\n\n\t$ git pull origin/foo\n\nwhich is not syntactically correct (unless you have origin/foo.git\nrepository) and should fail, but it resulted in a mysterious\naccess to the 'foo' subdirectory of the origin repository.\n\nWhich was what it was designed to do, but because this is an\noddball \"feature\" I suspect nobody uses, let's remove it.\n\nSigned-off-by: Junio C Hamano \n---\n git-parse-remote.sh | 34 +++++++---------------------------\n 1 files changed, 7 insertions(+), 27 deletions(-)\n\ndiff --git a/git-parse-remote.sh b/git-parse-remote.sh\nindex b163d22..aaef861 100755\n--- a/git-parse-remote.sh\n+++ b/git-parse-remote.sh\n@@ -7,18 +7,7 @@ GIT_DIR=$(git-rev-parse --git-dir 2>/dev/null) || :;\n get_data_source () {\n \tcase \"$1\" in\n \t*/*)\n-\t\t# Not so fast.\tThis could be the partial URL shorthand...\n-\t\ttoken=$(expr \"z$1\" : 'z\\([^/]*\\)/')\n-\t\tremainder=$(expr \"z$1\" : 'z[^/]*/\\(.*\\)')\n-\t\tif test \"$(git-repo-config --get \"remote.$token.url\")\"\n-\t\tthen\n-\t\t\techo config-partial\n-\t\telif test -f \"$GIT_DIR/branches/$token\"\n-\t\tthen\n-\t\t\techo branches-partial\n-\t\telse\n-\t\t\techo ''\n-\t\tfi\n+\t\techo ''\n \t\t;;\n \t*)\n \t\tif test \"$(git-repo-config --get \"remote.$1.url\")\"\n@@ -40,12 +29,7 @@ get_remote_url () {\n \tdata_source=$(get_data_source \"$1\")\n \tcase \"$data_source\" in\n \t'')\n-\t\techo \"$1\" ;;\n-\tconfig-partial)\n-\t\ttoken=$(expr \"z$1\" : 'z\\([^/]*\\)/')\n-\t\tremainder=$(expr \"z$1\" : 'z[^/]*/\\(.*\\)')\n-\t\turl=$(git-repo-config --get \"remote.$token.url\")\n-\t\techo \"$url/$remainder\"\n+\t\techo \"$1\"\n \t\t;;\n \tconfig)\n \t\tgit-repo-config --get \"remote.$1.url\"\n@@ -54,14 +38,10 @@ get_remote_url () {\n \t\tsed -ne '/^URL: */{\n \t\t\ts///p\n \t\t\tq\n-\t\t}' \"$GIT_DIR/remotes/$1\" ;;\n+\t\t}' \"$GIT_DIR/remotes/$1\"\n+\t\t;;\n \tbranches)\n-\t\tsed -e 's/#.*//' \"$GIT_DIR/branches/$1\" ;;\n-\tbranches-partial)\n-\t\ttoken=$(expr \"z$1\" : 'z\\([^/]*\\)/')\n-\t\tremainder=$(expr \"z$1\" : 'z[^/]*/\\(.*\\)')\n-\t\turl=$(sed -e 's/#.*//' \"$GIT_DIR/branches/$token\")\n-\t\techo \"$url/$remainder\"\n+\t\tsed -e 's/#.*//' \"$GIT_DIR/branches/$1\"\n \t\t;;\n \t*)\n \t\tdie \"internal error: get-remote-url $1\" ;;\n@@ -77,7 +57,7 @@ get_default_remote () {\n get_remote_default_refs_for_push () {\n \tdata_source=$(get_data_source \"$1\")\n \tcase \"$data_source\" in\n-\t'' | config-partial | branches | branches-partial)\n+\t'' | branches)\n \t\t;; # no default push mapping, just send matching refs.\n \tconfig)\n \t\tgit-repo-config --get-all \"remote.$1.push\" ;;\n@@ -196,7 +176,7 @@ canon_refs_list_for_fetch () {\n get_remote_default_refs_for_fetch () {\n \tdata_source=$(get_data_source \"$1\")\n \tcase \"$data_source\" in\n-\t'' | config-partial | branches-partial)\n+\t'')\n \t\techo \"HEAD:\" ;;\n \tconfig)\n \t\tcanon_refs_list_for_fetch -d \"$1\" \\\n-- \n1.4.4.3.ge228b\n"},{"id":"30137","messageId":"20061223031031.GA7412@socrates.priv","threadId":"6067","inReplyTo":"7vpsabv6tm.fsf@assigned-by-dhcp.cox.net","subject":"Re: confusion over the new branch and merge config","fromName":"Tom Prince","fromEmail":"tom.prince@ualberta.net","sentAt":"2006-12-23T03:10:31Z","receivedAt":"2006-12-23T03:10:31Z","isPatch":false,"sender":{"key":"tom.prince@ualberta.net","avatar":"https://gravatar.com/avatar/a0ad19caee7618876339485106ec994f5202505eecd210ba5c0bd869feaa555a?d=mp&s=160"},"body":"On Fri, Dec 22, 2006 at 03:39:33PM -0800, Junio C Hamano wrote:\n> [PATCH] Do not support \"partial URL shorthand\" anymore.\n> \n> We used to support specifying the top part of remote URL in\n> remotes and use that as a short-hand for the URL.\n> \n> \t$ cat .git/remotes/jgarzik\n> \tURL: git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/\n> \t$ git pull jgarzik/misc-2.6\n> \n> This is confusing when somebody attempts to do this:\n> \n> \t$ git pull origin/foo\n> \n> which is not syntactically correct (unless you have origin/foo.git\n> repository) and should fail, but it resulted in a mysterious\n> access to the 'foo' subdirectory of the origin repository.\n> \n> Which was what it was designed to do, but because this is an\n> oddball \"feature\" I suspect nobody uses, let's remove it.\n\nExcept with the forthcoming submodule support, this feature might become\nmore useful.\n\n Tom\n"},{"id":"30146","messageId":"Pine.LNX.4.64.0612230008190.18171@xanadu.home","threadId":"6067","inReplyTo":"7vpsabv6tm.fsf@assigned-by-dhcp.cox.net","subject":"Re: confusion over the new branch and merge config","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-23T05:11:06Z","receivedAt":"2006-12-23T05:11:06Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 22 Dec 2006, Junio C Hamano wrote:\n\n> Well, \"request\" was very inprecise word -- I should have said\n> \"suggestion\". But I think I agree.\n> \n> Seconds? Thirds?\n> \n> -- >8 --\n> [PATCH] Do not support \"partial URL shorthand\" anymore.\n> \n> We used to support specifying the top part of remote URL in\n> remotes and use that as a short-hand for the URL.\n> \n> \t$ cat .git/remotes/jgarzik\n> \tURL: git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/\n> \t$ git pull jgarzik/misc-2.6\n> \n> This is confusing when somebody attempts to do this:\n> \n> \t$ git pull origin/foo\n> \n> which is not syntactically correct (unless you have origin/foo.git\n> repository) and should fail, but it resulted in a mysterious\n> access to the 'foo' subdirectory of the origin repository.\n> \n> Which was what it was designed to do, but because this is an\n> oddball \"feature\" I suspect nobody uses, let's remove it.\n> \n> Signed-off-by: Junio C Hamano \n\nWell since I suggested it I seconds this of course.\n\nIf it ever becomes useful for, say, submodules as someone pointed out, \nthen this can be restored at that point and done properly for the task.\n\n\nNicolas\n"},{"id":"30147","messageId":"20061223051210.GA29814@segfault.peff.net","threadId":"6067","inReplyTo":"7vd56cam66.fsf@assigned-by-dhcp.cox.net","subject":"Re: confusion over the new branch and merge config","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-12-23T05:12:11Z","receivedAt":"2006-12-23T05:12:11Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Dec 21, 2006 at 03:01:21PM -0800, Junio C Hamano wrote:\n\n> > $ git checkout -b local_next origin/next\n> \n> \"git checkout -b next origin/next\" should work just fine, I\n> think.\n> \n> There was a talk about allowing \"checkout -b \" to\n> add branch..merge and branch..remote if can be\n> proven to corresond uniquely to one remote and one branch from\n> that remote; I think that would match the expectation most of\n> the time but that \"most\" would not be 100% nor even 80%, so I\n> think that should be an optional feature. In any case, there\n> was a talk but there is no code yet.\n\nBTW, is there some explanation why branch.*.merge specifies a _remote_\nhead? The following would make much more sense to me:\n\n[branch \"master\"]\nremote = origin\nmerge = refs/remotes/origin/master\n\nBecause I don't _care_ that the other guy calls it refs/heads/master. I\ncare that I'm pulling from refs/remotes/origin/master on my end (and\nhowever I get stuff into that branch is defined by the remote).\n\nIt also means that even without a remote, the merge option makes sense\n(e.g., if I do repeated merges from one local branch to another). And it\nmeans that it's _always_ correct for \"checkout -b \" to set\nbranch..merge to , without having to worry about finding an\nappropriate remote.\n\n-Peff\n"},{"id":"30152","messageId":"Pine.LNX.4.64.0612230028360.18171@xanadu.home","threadId":"6067","inReplyTo":"20061223051210.GA29814@segfault.peff.net","subject":"Re: confusion over the new branch and merge config","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-23T05:29:57Z","receivedAt":"2006-12-23T05:29:57Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 23 Dec 2006, Jeff King wrote:\n\n> BTW, is there some explanation why branch.*.merge specifies a _remote_\n> head? The following would make much more sense to me:\n> \n> [branch \"master\"]\n> remote = origin\n> merge = refs/remotes/origin/master\n> \n> Because I don't _care_ that the other guy calls it refs/heads/master. I\n> care that I'm pulling from refs/remotes/origin/master on my end (and\n> however I get stuff into that branch is defined by the remote).\n\nExactly the point I'm trying to make !\n\nI'm glad I'm not alone to come to this conclusion.\n\n\nNicolas\n"},{"id":"30154","messageId":"7vbqlvuoi4.fsf@assigned-by-dhcp.cox.net","threadId":"6067","inReplyTo":"20061223051210.GA29814@segfault.peff.net","subject":"Re: confusion over the new branch and merge config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-23T06:15:15Z","receivedAt":"2006-12-23T06:15:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> BTW, is there some explanation why branch.*.merge specifies a _remote_\n> head? The following would make much more sense to me:\n>\n> [branch \"master\"]\n> remote = origin\n> merge = refs/remotes/origin/master\n\nOnly *if* you store it in that tracking branch. The name the\nother party gives _do_ matter to you anyway, because you have to\n_know_ it to fetch. What it does NOT matter is if you use a\ntracking branch, or if you do, which local tracking branch you\nuse to track it.\n"},{"id":"30157","messageId":"20061223062209.GB9396@spearce.org","threadId":"6067","inReplyTo":"7vbqlvuoi4.fsf@assigned-by-dhcp.cox.net","subject":"Re: confusion over the new branch and merge config","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-23T06:22:09Z","receivedAt":"2006-12-23T06:22:09Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Jeff King writes:\n> \n> > BTW, is there some explanation why branch.*.merge specifies a _remote_\n> > head? The following would make much more sense to me:\n> >\n> > [branch \"master\"]\n> > remote = origin\n> > merge = refs/remotes/origin/master\n> \n> Only *if* you store it in that tracking branch. The name the\n> other party gives _do_ matter to you anyway, because you have to\n> _know_ it to fetch. What it does NOT matter is if you use a\n> tracking branch, or if you do, which local tracking branch you\n> use to track it.\n\nMy $0.02 USD (worth almost nothing these days!):\n\nI agree with Junio. branch..merge makes sense as the remote name.\n\n-- \nShawn.\n"},{"id":"30158","messageId":"20061223062801.GA5415@segfault.peff.net","threadId":"6067","inReplyTo":"7vbqlvuoi4.fsf@assigned-by-dhcp.cox.net","subject":"Re: confusion over the new branch and merge config","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-12-23T06:28:01Z","receivedAt":"2006-12-23T06:28:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Dec 22, 2006 at 10:15:15PM -0800, Junio C Hamano wrote:\n\n> Only *if* you store it in that tracking branch. The name the\n> other party gives _do_ matter to you anyway, because you have to\n> _know_ it to fetch. What it does NOT matter is if you use a\n> tracking branch, or if you do, which local tracking branch you\n> use to track it.\n\nNo, their names _don't_ matter to most users. With the new remote layout\nand wildcards, I'll never even see 'refs/heads/next' when I clone\ngit.git; I'll only talk about 'origin/next'. The local tracking branch\nmatters much more to me, because it's the thing I'll use to interact\nwith git. I don't say 'git-checkout -b topic origin refs/heads/master';\nI say 'git-checkout -b topic origin/next'.\n\nYes, my proposed syntax means you have to have a tracking branch. But\ndoes it really make sense for people to put entries in their config\nfile, but not have a tracking branch? What do people use non-tracking\nbranch pulls for, anyway? I would assume for one-off pulls of\ninfrequently used repositories, in which case they're always saying\n\"git-pull git://path/to/repo foo:bar\". My point being that if we can\nimprove the usefulness of the config file, it's probably not worth\nworrying about people combining branch.*.merge config entries with\nnon-tracking-branch pulls, since they're extremely unlikely to be used\ntogether.\n\nDoes anyone out there use non-tracking-branch pulls? If so, can you\ndescribe your use case?\n\n-Peff\n"},{"id":"30160","messageId":"7vy7ozt7c9.fsf@assigned-by-dhcp.cox.net","threadId":"6067","inReplyTo":"20061223062801.GA5415@segfault.peff.net","subject":"Re: confusion over the new branch and merge config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-23T07:11:18Z","receivedAt":"2006-12-23T07:11:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Yes, my proposed syntax means you have to have a tracking branch. But\n> does it really make sense for people to put entries in their config\n> file, but not have a tracking branch? What do people use non-tracking\n> branch pulls for, anyway? I would assume for one-off pulls of\n> infrequently used repositories, in which case they're always saying\n> \"git-pull git://path/to/repo foo:bar\".\n\nNot at all. I pull from gitk repository and I do not have\ntracking branch, but I still have a remote defined for it.\n"},{"id":"30161","messageId":"20061223072507.GA8974@segfault.peff.net","threadId":"6067","inReplyTo":"7vy7ozt7c9.fsf@assigned-by-dhcp.cox.net","subject":"Re: confusion over the new branch and merge config","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-12-23T07:25:07Z","receivedAt":"2006-12-23T07:25:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Dec 22, 2006 at 11:11:18PM -0800, Junio C Hamano wrote:\n\n> Not at all. I pull from gitk repository and I do not have\n> tracking branch, but I still have a remote defined for it.\n\nDo you also define branch.*.merge to use with this? Is there a reason\nyou don't want a tracking branch?\n\n-Peff\n"},{"id":"30183","messageId":"emipbt$f4m$3@sea.gmane.org","threadId":"6067","inReplyTo":"20061223051210.GA29814@segfault.peff.net","subject":"Re: confusion over the new branch and merge config","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-23T08:31:29Z","receivedAt":"2006-12-23T08:31:29Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jeff King wrote:\n\n> It also means that even without a remote, the merge option makes sense\n> (e.g., if I do repeated merges from one local branch to another). And it\n> means that it's _always_ correct for \"checkout -b \" to set\n> branch..merge to , without having to worry about finding an\n> appropriate remote.\n\nWithout remote (or rather with remote \".\") remote branch names are the same\nas tracking branch names :-)\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"30191","messageId":"7vbqlvrldk.fsf@assigned-by-dhcp.cox.net","threadId":"6067","inReplyTo":"7vbqlvuoi4.fsf@assigned-by-dhcp.cox.net","subject":"Re: confusion over the new branch and merge config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-23T09:51:03Z","receivedAt":"2006-12-23T09:51:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Jeff King writes:\n>\n>> BTW, is there some explanation why branch.*.merge specifies a _remote_\n>> head? The following would make much more sense to me:\n>>\n>> [branch \"master\"]\n>> remote = origin\n>> merge = refs/remotes/origin/master\n>\n> Only *if* you store it in that tracking branch. The name the\n> other party gives _do_ matter to you anyway, because you have to\n> _know_ it to fetch. What it does NOT matter is if you use a\n> tracking branch, or if you do, which local tracking branch you\n> use to track it.\n\nHaving said that, I think we _could_ do this.\n\nIf you (or other people) use branch.*.merge, with its value set\nto remote name _and_ local name, and actually verify that either\nform works without confusion, please report back and I'll apply.\n\nMy scar is still fresh from the \"not having branch.*.merge is an\nerror\" mistake, where the thing stayed on 'next' for the better\npart of last week without anybody complaining, and immediately\nbroken peoples' workflows when it was pushed out to 'master'.\n\nI really do not want to repeat that.\n\n-- >8 --\n\ndiff --git a/git-parse-remote.sh b/git-parse-remote.sh\nindex aaef861..b45af5c 100755\n--- a/git-parse-remote.sh\n+++ b/git-parse-remote.sh\n@@ -146,8 +146,13 @@ canon_refs_list_for_fetch () {\n \t\telse\n \t\t\tfor merge_branch in $merge_branches\n \t\t\tdo\n-\t\t\t [ \"$remote\" = \"$merge_branch\" ] &&\n-\t\t\t dot_prefix= && break\n+\t\t\t if\ttest \"$remote\" = \"$merge_branch\" ||\n+\t\t\t\ttest \"z$local\" != z &&\n+\t\t\t \ttest \"$local\" = \"$merge_branch\"\n+\t\t\t then\n+\t\t\t\t dot_prefix=\n+\t\t\t\t break\n+\t\t\t fi\n \t\t\tdone\n \t\tfi\n \t\tcase \"$remote\" in\n"},{"id":"30193","messageId":"emj0uh$21s$1@sea.gmane.org","threadId":"6067","inReplyTo":"7vbqlvrldk.fsf@assigned-by-dhcp.cox.net","subject":"Re: confusion over the new branch and merge config","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-23T10:40:53Z","receivedAt":"2006-12-23T10:40:53Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n>> Only *if* you store it in that tracking branch.  The name the\n>> other party gives _do_ matter to you anyway, because you have to\n>> _know_ it to fetch.  What it does NOT matter is if you use a\n>> tracking branch, or if you do, which local tracking branch you\n>> use to track it.\n> \n> Having said that, I think we _could_ do this.\n> \n> If you (or other people) use branch.*.merge, with its value set\n> to remote name _and_ local name, and actually verify that either\n> form works without confusion, please report back and I'll apply.\n\nHmmm... that DWIM is even better than proposed some time ago localmerge\n(or mergelocal, I don't remember) config variable.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"30205","messageId":"Pine.LNX.4.63.0612231655420.19693@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6067","inReplyTo":"7vbqlvrldk.fsf@assigned-by-dhcp.cox.net","subject":"Re: confusion over the new branch and merge config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-23T15:58:07Z","receivedAt":"2006-12-23T15:58:07Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 23 Dec 2006, Junio C Hamano wrote:\n\n> Junio C Hamano writes:\n> \n> > Jeff King writes:\n> >\n> >> BTW, is there some explanation why branch.*.merge specifies a _remote_\n> >> head? The following would make much more sense to me:\n> >>\n> >> [branch \"master\"]\n> >> remote = origin\n> >> merge = refs/remotes/origin/master\n> >\n> > Only *if* you store it in that tracking branch. The name the\n> > other party gives _do_ matter to you anyway, because you have to\n> > _know_ it to fetch. What it does NOT matter is if you use a\n> > tracking branch, or if you do, which local tracking branch you\n> > use to track it.\n> \n> Having said that, I think we _could_ do this.\n> \n> If you (or other people) use branch.*.merge, with its value set\n> to remote name _and_ local name, and actually verify that either\n> form works without confusion, please report back and I'll apply.\n\nI do not claim to understand your patch (I have no idea if || or && is \nstronger in shell), but here is another proposition: if the config \nvariablÃe starts with \"refsremotes/\", assume it is local.\n\nCiao,\nDscho\n"},{"id":"30214","messageId":"emkbhq$amu$1@sea.gmane.org","threadId":"6067","inReplyTo":"Pine.LNX.4.63.0612231655420.19693@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: confusion over the new branch and merge config","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-23T22:48:00Z","receivedAt":"2006-12-23T22:48:00Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> On Sat, 23 Dec 2006, Junio C Hamano wrote:\n\n>> Having said that, I think we _could_ do this.\n>> \n>> If you (or other people) use branch.*.merge, with its value set\n>> to remote name _and_ local name, and actually verify that either\n>> form works without confusion, please report back and I'll apply.\n> \n> I do not claim to understand your patch (I have no idea if || or && is \n> stronger in shell), but here is another proposition: if the config \n> variable starts with \"refs/remotes/\", assume it is local.\n\nWhy? You can track another repository tracking branches, using it as a kind\nof proxy repository, even if it is not bare...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"30229","messageId":"20061224061549.GA17186@segfault.peff.net","threadId":"6067","inReplyTo":"7vbqlvrldk.fsf@assigned-by-dhcp.cox.net","subject":"Re: confusion over the new branch and merge config","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-12-24T06:15:50Z","receivedAt":"2006-12-24T06:15:50Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Dec 23, 2006 at 01:51:03AM -0800, Junio C Hamano wrote:\n\n> If you (or other people) use branch.*.merge, with its value set\n> to remote name _and_ local name, and actually verify that either\n> form works without confusion, please report back and I'll apply.\n\nI am happy to try this out and report back. However, I'm out of town for\nthe holidays, so I won't have anything useful to say until next week.\n\n-Peff\n"},{"id":"30256","messageId":"Pine.LNX.4.64.0612241544250.18171@xanadu.home","threadId":"6067","inReplyTo":"7vbqlvrldk.fsf@assigned-by-dhcp.cox.net","subject":"Re: confusion over the new branch and merge config","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-24T20:49:50Z","receivedAt":"2006-12-24T20:49:50Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 23 Dec 2006, Junio C Hamano wrote:\n\n> If you (or other people) use branch.*.merge, with its value set\n> to remote name _and_ local name, and actually verify that either\n> form works without confusion, please report back and I'll apply.\n\nThis is nice, thanks.\n\nWhat would be nice as well is to be able to provide only the _name_ of \nthe tracking branch without the refs/remotes/$origin/ prefix. Since \nthere is already a 'branch.\"blah\".remote = $origin' entry, then having \n'branch.\"blah\".merge = $foo' could mean \"refs/remotes/$origin/$foo\" when \n$foo contains no slash.\n\n\nNicolas\n"},{"id":"30296","messageId":"20061226073346.GA22218@segfault.peff.net","threadId":"6067","inReplyTo":"Pine.LNX.4.64.0612241544250.18171@xanadu.home","subject":"Re: confusion over the new branch and merge config","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-12-26T07:33:49Z","receivedAt":"2006-12-26T07:33:49Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Dec 24, 2006 at 03:49:50PM -0500, Nicolas Pitre wrote:\n\n> What would be nice as well is to be able to provide only the _name_ of \n> the tracking branch without the refs/remotes/$origin/ prefix. Since \n> there is already a 'branch.\"blah\".remote = $origin' entry, then having \n> 'branch.\"blah\".merge = $foo' could mean \"refs/remotes/$origin/$foo\" when \n> $foo contains no slash.\n\nNAK. That makes branch names like \"jc/foo\" second-class citizens. You\nwould do better to say \"entries without refs/ are implicitly local refs\nin refs/remotes/\".\n\n-Peff\n"},{"id":"30671","messageId":"20070102144940.GA23932@coredump.intra.peff.net","threadId":"6067","inReplyTo":"7vbqlvrldk.fsf@assigned-by-dhcp.cox.net","subject":"Re: confusion over the new branch and merge config","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-01-02T14:49:40Z","receivedAt":"2007-01-02T14:49:40Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Dec 23, 2006 at 01:51:03AM -0800, Junio C Hamano wrote:\n\n> If you (or other people) use branch.*.merge, with its value set\n> to remote name _and_ local name, and actually verify that either\n> form works without confusion, please report back and I'll apply.\n\nThis [using tracking branches in branch.*.merge] seems to be working for\nme, but it is possible to get some confusing results with it. Try this\nconfig:\n\n[remote \"origin\"]\n url = /my/other/git/repo\n fetch = refs/heads/master:refs/heads/origin\n fetch = refs/heads/origin:refs/heads/junio\n[branch \"master\"]\n remote = origin\n merge = refs/heads/origin\n\nThat is, we have a local tracking branch 'X' which has the same name as\na remote branch 'X'. When we fetch, both will be marked for merge in\nFETCH_HEAD, and git-pull will attempt to do an octopus.\n\nIs this too convoluted a config to worry about (no, I don't actually do\nthis in my repository -- I just constructed the most plausible reason I\ncould think of for having conflicting names). I actually think having a\nbranch.*.mergelocal would make just as much sense and would be more\nrobust (plus, it should be safe and sensible for \"git-checkout -b foo\nbar\" to point branch.foo.mergelocal to refs/heads/bar).\n\n-Peff\n"},{"id":"30674","messageId":"7vps9xwd01.fsf@assigned-by-dhcp.cox.net","threadId":"6067","inReplyTo":"20070102144940.GA23932@coredump.intra.peff.net","subject":"Re: confusion over the new branch and merge config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-02T17:32:30Z","receivedAt":"2007-01-02T17:32:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Sat, Dec 23, 2006 at 01:51:03AM -0800, Junio C Hamano wrote:\n>\n>> If you (or other people) use branch.*.merge, with its value set\n>> to remote name _and_ local name, and actually verify that either\n>> form works without confusion, please report back and I'll apply.\n>\n> This [using tracking branches in branch.*.merge] seems to be working for\n> me, but it is possible to get some confusing results with it. Try this\n> config:\n>\n> [remote \"origin\"]\n> url = /my/other/git/repo\n> fetch = refs/heads/master:refs/heads/origin\n> fetch = refs/heads/origin:refs/heads/junio\n> [branch \"master\"]\n> remote = origin\n> merge = refs/heads/origin\n>\n> That is, we have a local tracking branch 'X' which has the same name as\n> a remote branch 'X'. When we fetch, both will be marked for merge in\n> FETCH_HEAD, and git-pull will attempt to do an octopus.\n>\n> Is this too convoluted a config to worry about (no, I don't actually do\n> this in my repository -- I just constructed the most plausible reason I\n> could think of for having conflicting names). I actually think having a\n> branch.*.mergelocal would make just as much sense and would be more\n> robust (plus, it should be safe and sensible for \"git-checkout -b foo\n> bar\" to point branch.foo.mergelocal to refs/heads/bar).\n\nIf we are to worry about, and I think we might have to, I think\nnot worrying about mergelocal and not accepting the name of\nlocal tracking branch is the only sensible thing to do.\n\nIs there a problem if we did that? I do not think of any.\n"},{"id":"30675","messageId":"20070102173410.GA25325@coredump.intra.peff.net","threadId":"6067","inReplyTo":"7vps9xwd01.fsf@assigned-by-dhcp.cox.net","subject":"Re: confusion over the new branch and merge config","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-01-02T17:34:11Z","receivedAt":"2007-01-02T17:34:11Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 02, 2007 at 09:32:30AM -0800, Junio C Hamano wrote:\n\n> If we are to worry about, and I think we might have to, I think\n> not worrying about mergelocal and not accepting the name of\n> local tracking branch is the only sensible thing to do.\n\nSorry, I don't see the problem with mergelocal. Can you elaborate?\n\n-Peff\n"},{"id":"30692","messageId":"7v1wmdure6.fsf@assigned-by-dhcp.cox.net","threadId":"6067","inReplyTo":"20070102173410.GA25325@coredump.intra.peff.net","subject":"Re: confusion over the new branch and merge config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-02T20:04:33Z","receivedAt":"2007-01-02T20:04:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Tue, Jan 02, 2007 at 09:32:30AM -0800, Junio C Hamano wrote:\n>\n>> If we are to worry about, and I think we might have to, I think\n>> not worrying about mergelocal and not accepting the name of\n>> local tracking branch is the only sensible thing to do.\n>\n> Sorry, I don't see the problem with mergelocal. Can you elaborate?\n\nI might have misread what you meant by mergeLocal, and you might\nbe trying to introduce a default for \"git merge\" so that without\nanything on the command line \"git merge\" would merge something\nlocally available depending on which branch you are on.\n\nBut I did not think of that, and thought you were saying \"look\nat branch.*.mergelocal (if exists) in the same place we look at\nbranch.*.merge in the current code, and just like the latter is\nused to match up with the remote refname we just fetched, use\nthe former to match the local tracking branches, to decide what\nto merge\". And if that is what you meant by mergelocal, I do\nnot see much advantage in that approach -- that is what I meant\nin the response. The remote name is available whether you use\ntracking branches locally or not, so using that to specify the\nmerge operation that happens after a 'pull' is more consistent,\nless confusing, and matches the long-hand \"git pull $URL\nremote-branch\" a lot better than having another configuration\nthat can be used only half the time.\n\nSome people repeatedly argued that remote branch names do not\nmatter. I think they are wrong and are missing the point of\ndistributedness of git. You are fetching from there, so you\nneed to know the name the other end gives them in the first\nplace. But much more importantly, the fact you are fetching\nfrom there means some other people could also be fetching from\nthe same place. Now how would you discuss what that common\nrepository recently placed on that branch? You would not use\nthe local tracking branch name which _is_ meaningless to the\nother person. You use the remote name.\n\nFor example, I have a separate repository (that happens to be\nchecked out in Meta/ subdirectory of my main working area, so\nits control files are in Meta/.git repository) to keep things\nthat I push to my 'todo' branch. After I push the updates to\n'todo' out to kernel.org from that repository, I usually fetch\nfrom kernel.org into that repository, so that I can later see up\nto which one I have already pushed out. I am old fashioned and\nstill use remotes and non 'separate-remote' layout for this:\n\n\tURL: kernel.org:/pub/scm/git/git.git\n Push: refs/heads/master:refs/heads/todo\n Pull: refs/heads/todo:refs/heads/ko\n\nAs you can see from the above, my 'ko' is the local tracking\nbranch, and 'master' in that repository is what is known as\n'todo' to the public. But when I talk about what I have in that\nbranch, I would never say 'master' nor 'ko' -- people would not\ncare how I call that branch locally in my private repository.\nWhat's private is private and does not matter to others.\nInstead I would say something like \"my 'todo' branch has drafts\nfor v1.5.0 release notes these days\".\n\nWhat does this all mean? It means that remote branch names\nmatter more when you are talking about external communication.\nAnd \"git pull\" (more so for \"git fetch\") is all about external\ncommunication.\n\nObviously, the local names should matter more when you are doing\nlocal operations. So if you are using mergeLocal to give a\nshorthand to \"git merge\" that does not explicitly say what to\nmerge, the above discussion does not apply. But if that is the\ncase, mergeLocal should also not affect the selection of\nbranches to be merged when \"git pull\" happens from a remote\neither.\n"},{"id":"30694","messageId":"enef73$467$1@sea.gmane.org","threadId":"6067","inReplyTo":"7v1wmdure6.fsf@assigned-by-dhcp.cox.net","subject":"Re: confusion over the new branch and merge config","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-02T20:30:21Z","receivedAt":"2007-01-02T20:30:21Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Obviously, the local names should matter more when you are doing\n> local operations.  So if you are using mergeLocal to give a\n> shorthand to \"git merge\" that does not explicitly say what to\n> merge, the above discussion does not apply.  But if that is the\n> case, mergeLocal should also not affect the selection of\n> branches to be merged when \"git pull\" happens from a remote\n> either.\n\nYou can always use remote = \".\", and then remote and local branches\nare the same...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"30720","messageId":"8aa486160701021624v69015fbibb81a99177dd7dfc@mail.gmail.com","threadId":"6067","inReplyTo":"enef73$467$1@sea.gmane.org","subject":"Re: confusion over the new branch and merge config","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2007-01-03T00:24:33Z","receivedAt":"2007-01-03T00:24:33Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On 1/2/07, Jakub Narebski wrote:\n> Junio C Hamano wrote:\n>\n> > Obviously, the local names should matter more when you are doing\n> > local operations. So if you are using mergeLocal to give a\n> > shorthand to \"git merge\" that does not explicitly say what to\n> > merge, the above discussion does not apply. But if that is the\n> > case, mergeLocal should also not affect the selection of\n> > branches to be merged when \"git pull\" happens from a remote\n> > either.\n>\n> You can always use remote = \".\", and then remote and local branches\n> are the same...\n\nCurrently it does not work.\n\nSanti\n"},{"id":"30778","messageId":"200701040002.20773.jnareb@gmail.com","threadId":"6067","inReplyTo":"8aa486160701021624v69015fbibb81a99177dd7dfc@mail.gmail.com","subject":"Re: confusion over the new branch and merge config","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-03T23:02:20Z","receivedAt":"2007-01-03T23:02:20Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Santi Béjar wrote:\n> On 1/2/07, Jakub Narebski wrote:\n>> Junio C Hamano wrote:\n>>\n>>> Obviously, the local names should matter more when you are doing\n>>> local operations. So if you are using mergeLocal to give a\n>>> shorthand to \"git merge\" that does not explicitly say what to\n>>> merge, the above discussion does not apply. But if that is the\n>>> case, mergeLocal should also not affect the selection of\n>>> branches to be merged when \"git pull\" happens from a remote\n>>> either.\n>>\n>> You can always use remote = \".\", and then remote and local branches\n>> are the same...\n> \n> Currently it does not work.\n\nFact.\n\nI remember that there was proposal of having branch..remote=.\nand branch..merge= to make \"git pull\" on branch \ndo \"git pull . \". There was some discussion about this; perhaps\nit was not accepted (or forgotten to be accepted after resolving\ndiscussion).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"31249","messageId":"20070109150524.GB10633@coredump.intra.peff.net","threadId":"6067","inReplyTo":"7v1wmdure6.fsf@assigned-by-dhcp.cox.net","subject":"Re: confusion over the new branch and merge config","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-01-09T15:05:24Z","receivedAt":"2007-01-09T15:05:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"[sorry this is old, but hopefully you remember what we were talking\nabout. :)]\n\nOn Tue, Jan 02, 2007 at 12:04:33PM -0800, Junio C Hamano wrote:\n\n> I might have misread what you meant by mergeLocal, and you might\n> be trying to introduce a default for \"git merge\" so that without\n> anything on the command line \"git merge\" would merge something\n> locally available depending on which branch you are on.\n\nNo, I think you read me right: I wanted a way of saying \"this is the\nlocal branch from which merges should happen if no other branch is\nspecified\".\n\n> But I did not think of that, and thought you were saying \"look\n> at branch.*.mergelocal (if exists) in the same place we look at\n> branch.*.merge in the current code, and just like the latter is\n> used to match up with the remote refname we just fetched, use\n> the former to match the local tracking branches, to decide what\n> to merge\". And if that is what you meant by mergelocal, I do\n> not see much advantage in that approach -- that is what I meant\n> in the response. The remote name is available whether you use\n> tracking branches locally or not, so using that to specify the\n> merge operation that happens after a 'pull' is more consistent,\n> less confusing, and matches the long-hand \"git pull $URL\n> remote-branch\" a lot better than having another configuration\n> that can be used only half the time.\n\nLet me say right now that I'm not _that_ interested in this concept, so\nI'm going to stop pushing for it. However, I do want to respond to a few\npoints in this mail; feel free to ignore. :)\n\nThere are two advantages I see to putting local branches in branch.*.merge:\n\n 1. there seems to be some newbie confusion over using the remote name.\n Pull is conceptually (to me anyway), two steps:\n 1. Fetch from a remote into my local tracking branches\n 2. Merge from some tracking branch into my current branch.\n whereas I have seen you explain pull as:\n 1. Fetch into FETCH_HEAD, selecting some branches for merge\n 2. Merge any branches marked for merge\n I know that your model is more flexible, since it supports skipping\n the tracking branches. But for newbies looking at the config, I\n think the first makes much more sense.\n 1. Newbies always have tracking branches, since that's now the\n default layout.\n 2. Newbies don't know about FETCH_HEAD, since we don't talk about\n it in tutorials (and really, with tracking branches, what's the\n point?).\n 3. Out of the two steps (fetching and merging), I would expect the\n .merge config option to be dealth with in the latter. But\n actually, it is an intimate part of fetching. This doesn't\n matter if you're pulling, but my workflow (and many others, it\n seems, especially those who rebase regularly) is:\n git fetch\n gitk master...origin\n git rebase ;# or git-pull\n\n 2. There has been a requested feature (which I think makes sense) to\n create an automatic \"upstream\" for local branches. I.e.,\n git checkout -b new old\n hack hack hack\n git pull ;# should pull from 'old'\n This should be trivial to implement as\n git-repo-config branch.$new.mergeLocal $old\n but instead is requiring some magic to treat '.' as a noop remote.\n\n[This ends the productive portion of this mail, but read on for more\nphilosophical wanderings.]\n\n> Some people repeatedly argued that remote branch names do not\n> matter. I think they are wrong and are missing the point of\n> distributedness of git. You are fetching from there, so you\n\nI think the opposite. :)\n\nTo me, the distributed part of git (and one of its strengths over other\nsystems) is that we are all working on a giant digraph of the history,\nand git is very efficient at adding to, examining, and communicating\nabout parts of that graph.\n\nRefs are just pointers into the graph, and so the names we give them are\nmostly just local matters (unless we're publishing those names). For\nexample, before I started using separate remotes, I had what by many\nwould be considered a funny setup. I was used to working with master and\norigin, but I wanted to start tracking next instead. So I made my origin\ntrack your next, and I called my master what you call next (plus local\ncommits). As a result, I called your master 'stable' so I could still\naccess it. So the history was distributed, but the names were\ncompletely local.\n\nAnother oft-mentioned example from the big bzr debate is a fork: what if\nI stop pulling from you, and start pulling from somebody else? The\npointers have changed, but the underlying history is inherently the\nsame. There's no penalty for me to switch names.\n\nThat isn't to say the names of the pointers are without value. Talking\nabout 'master' and 'next' is very useful for humans. But what we\n_really_ mean is \"Junio's master\" and \"Junio's next\", because you are\npublishing those pointers. I don't know (or care) what's on Linus'\nmaster, so he can call it whatever he wants. Or if I do care, I don't\nnecessarily care how it relates to your master. So to me, getting hung\nup on remote names (that is, treating them as anything besides\npublishing points) misses the point of git's distributedness.\n\nWhich isn't to say branch.*.merge looking at remote refs is _wrong_, but\nthat using local names is at least as right (conceptually). :)\n\n> the same place. Now how would you discuss what that common\n> repository recently placed on that branch? You would not use\n> the local tracking branch name which _is_ meaningless to the\n> other person. You use the remote name.\n\nSure, you would. Because you're talking about that other repo. But my\nmental model is that all git operations are local operations, except for\nfetching and pushing. I really think of pull as a shorthand \"git-fetch;\ngit-merge\". So to me, git-merge is a local operation that should deal\nwith local names.\n\n> As you can see from the above, my 'ko' is the local tracking\n> branch, and 'master' in that repository is what is known as\n> 'todo' to the public. But when I talk about what I have in that\n> branch, I would never say 'master' nor 'ko' -- people would not\n> care how I call that branch locally in my private repository.\n> What's private is private and does not matter to others.\n> Instead I would say something like \"my 'todo' branch has drafts\n> for v1.5.0 release notes these days\".\n\nExactly. Only published names matter to other people. However, I contend\nthat published names stop mattering once you have a mapping to local\nnames.\n\n> What does this all mean? It means that remote branch names\n> matter more when you are talking about external communication.\n> And \"git pull\" (more so for \"git fetch\") is all about external\n> communication.\n\nI think this is where we really disagree. As I said, git-pull is really\njust \"fetch+merge\" to me. And merge isn't about external communication.\n\n> Obviously, the local names should matter more when you are doing\n> local operations. So if you are using mergeLocal to give a\n> shorthand to \"git merge\" that does not explicitly say what to\n> merge, the above discussion does not apply. But if that is the\n\nWhat I'm suggesting is that it can be used for either (local merges or\npulls, since both are git-merge.\n\n> case, mergeLocal should also not affect the selection of\n> branches to be merged when \"git pull\" happens from a remote\n> either.\n\nI think I am fundamentally denying the way \"for-merge\" branch selection\nworks in git-pull. That is, it isn't the way I think of it conceptually,\nperhaps because I don't actually 'pull' very often. I _always_ fetch\nfirst.\n\n-Peff\n"},{"id":"31256","messageId":"20070109161832.GA9577@coredump.intra.peff.net","threadId":"6067","inReplyTo":"20070109150524.GB10633@coredump.intra.peff.net","subject":"Re: confusion over the new branch and merge config","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-01-09T16:18:32Z","receivedAt":"2007-01-09T16:18:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 09, 2007 at 10:05:24AM -0500, Jeff King wrote:\n\n> There are two advantages I see to putting local branches in branch.*.merge:\n\nLet me add a third:\n\nThere are some operations which care about who our upstream is, but\ndidn't necessarily just do a fetch (so FETCH_HEAD is not an option). For\nexample, I have a short porcelain-ish script that formats all of my\nchanges as patches and shows them as a mutt mailbox. If you don't\nspecify an upstream, it uses 'origin'. However, this isn't right if I'm\non 'next'. What I _really_ want is to say \"a sensible upstream branch\nfor the branch I'm currently on\" which is basically what \"mergeLocal\"\nwould be.\n\nCome to think of it, mergeLocal is a terrible name, since it should\nreally would be for merging, rebasing, and anything else which wanted to\nsay \"where did I probably come from?\" So perhaps \"upstream\" would make\nmore sense?\n\n-Peff\n"}]}