{"thread":{"id":"6075","subject":"What's in git.git (stable)","startedAt":"2006-12-22T09:25:52Z","lastAt":"2006-12-27T02:14:24Z","messageCount":20,"participants":["Junio C Hamano","Randal L. Schwartz","Johannes Schindelin","Jakub Narebski","Quy Tonthat","Luben Tuikov"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"30034","messageId":"7vodpw46zj.fsf@assigned-by-dhcp.cox.net","threadId":"6075","inReplyTo":null,"subject":"What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-22T09:25:52Z","receivedAt":"2006-12-22T09:25:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I guess I'll need to push another maintenance release out soon,\nif only to fix the manual pages.\n\nOn the 'master' front there are a handful more topics pushed out\nfrom 'next'. I still need to apply the __FREEBSD__ fix yet, but\notherwise we should be able to start calming things down.\n\n* The 'maint' branch has these fixes since the last announcement.\n\n Johannes Schindelin (1):\n diff --check: fix off by one error\n\n Junio C Hamano (1):\n spurious .sp in manpages\n\n* The 'master' branch has these since the last announcement.\n\n Eric Wong (3):\n git-svn: convert to using Git.pm\n git-svn: remove support for the svn command-line client\n git-svn: rename 'commit' command to 'set-tree'\n\n Johannes Schindelin (5):\n Introduce GIT_TEMPLATE_DIR\n diff --check: fix off by one error\n Use git-merge-file in git-merge-one-file, too\n git-tag: support -F option\n git-reset --hard: tell the user what the HEAD was reset to\n\n Josef Weidendorfer (1):\n Move \"no merge candidate\" warning into git-pull\n\n Junio C Hamano (22):\n git-clone: use wildcard specification for tracking branches\n git-pull: refuse default merge without branch.*.merge\n git-clone: lose the artificial \"first\" fetch refspec\n git-clone: lose the traditional 'no-separate-remote' layout\n rev-list --left-right\n Teach all of log family --left-right output.\n Make left-right automatic.\n fix testsuite: make sure they use templates freshly built from the source\n Teach git-branch to delete tracking branches with -r -d\n blame: -b (blame.blankboundary) and --root (blame.showroot)\n Revert \"fix testsuite: make sure they use templates freshly\n built from the source\"\n Do not create $GIT_DIR/remotes/ directory anymore.\n Use preprocessor constants for environment variable names.\n Revert \"Make left-right automatic.\"\n git-add: error out when given no arguments.\n spurious .sp in manpages\n compat/inet_ntop: do not use u_int\n diff documentation: mostly talk about \n Revert \"git-pull: refuse default merge without branch.*.merge\"\n parse-remote: mark all refs not for merge only when fetching more\n than one\n _XOPEN_SOURCE problem also exists on FreeBSD\n commit-tree: do not overflow MAXPARENT\n\n Quy Tonthat (2):\n git-branch -d: do not stop at the first failure.\n Documentation/git-branch: new -r to delete remote-tracking branches.\n\n Shawn Pearce (3):\n Suggest 'add' in am/revert/cherry-pick.\n Rename imap-send's internal info/warn functions.\n Introduce a global level warn() function.\n\n Terje Sten Bjerkseth (1):\n Fix system header problems on Mac OS X\n"},{"id":"30069","messageId":"86k60jsvh8.fsf@blue.stonehenge.com","threadId":"6075","inReplyTo":"7vodpw46zj.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable)","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-12-22T17:15:15Z","receivedAt":"2006-12-22T17:15:15Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Junio\" == Junio C Hamano writes:\n\nJunio> git-pull: refuse default merge without branch.*.merge\n\nArgh. How do I get back the old behavior?\n\"git-pull origin\" doesn't seem to be enough.\n\nYou just broke a bunch of automated scripts for me.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"30070","messageId":"86fyb7sv9f.fsf@blue.stonehenge.com","threadId":"6075","inReplyTo":"86k60jsvh8.fsf@blue.stonehenge.com","subject":"Re: What's in git.git (stable)","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-12-22T17:19:56Z","receivedAt":"2006-12-22T17:19:56Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Randal\" == Randal L Schwartz writes:\n\n>>>>> \"Junio\" == Junio C Hamano writes:\nJunio> git-pull: refuse default merge without branch.*.merge\n\nRandal> Argh. How do I get back the old behavior?\nRandal> \"git-pull origin\" doesn't seem to be enough.\n\nRandal> You just broke a bunch of automated scripts for me.\n\nAhh, it's \"git-pull . origin\".\n\nMaybe a bit more warning for non-upward-compatible changes though, please.\n\nOr maybe we should presume everything is non-upward compatible? I didn't\nthink a naked \"git-pull\" was that out of the ordinary.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"30074","messageId":"Pine.LNX.4.63.0612221902490.19693@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6075","inReplyTo":"86fyb7sv9f.fsf@blue.stonehenge.com","subject":"Re: What's in git.git (stable)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-22T18:09:40Z","receivedAt":"2006-12-22T18:09:40Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 22 Dec 2006, Randal L. Schwartz wrote:\n\n> >>>>> \"Randal\" == Randal L Schwartz writes:\n> \n> >>>>> \"Junio\" == Junio C Hamano writes:\n> Junio> git-pull: refuse default merge without branch.*.merge\n> \n> Randal> Argh. How do I get back the old behavior?\n> Randal> \"git-pull origin\" doesn't seem to be enough.\n\nMaybe \"git-pull origin master\"?\n\n> Randal> You just broke a bunch of automated scripts for me.\n> \n> Ahh, it's \"git-pull . origin\".\n\nThis is just a merge, not a real pull (it leaves out the fetch part).\n\n> Maybe a bit more warning for non-upward-compatible changes though, \n> please.\n\nIt is unfortunate that this change broke your scripts. But I really think \nthat the new behaviour is much saner: If you have different branches, you \nprobably do not want to pull the _same_ remote branch into _all_ of them.\n\nSo, for each branch (e.g. \"xyz\") for which you have a preferred upstream \n(e.g. remote \"linus\" with branch \"master\"), say\n\n\t$ git repo-config branch.xyz.remote linus\n\t$ git repo-config branch.xyz.merge refs/heads/master\n\nThen,\n\n\t$ git pull\n\npulls your preferred upstream. But when you pull from another remote, or \ninto another branch, without specifying which remote branch you want to \npull, git now refuses to blindly pull branch \"master\". This should prevent \nquite some pilot errors.\n\nCiao,\nDscho\n"},{"id":"30075","messageId":"861wmrsstc.fsf@blue.stonehenge.com","threadId":"6075","inReplyTo":"Pine.LNX.4.63.0612221902490.19693@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: What's in git.git (stable)","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-12-22T18:12:47Z","receivedAt":"2006-12-22T18:12:47Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Johannes\" == Johannes Schindelin writes:\n\n>> Ahh, it's \"git-pull . origin\".\n\nJohannes> This is just a merge, not a real pull (it leaves out the fetch part).\n\nOK, so what does what a naked \"git-pull\" used to do before, which was\n\"fetch origin, then pull it into the current branch\"?\n\nJohannes> So, for each branch (e.g. \"xyz\") for which you have a preferred upstream \nJohannes> (e.g. remote \"linus\" with branch \"master\"), say\n\nJohannes> \t$ git repo-config branch.xyz.remote linus\nJohannes> \t$ git repo-config branch.xyz.merge refs/heads/master\n\nBut that's not upward compatible. The default should be the old behavior,\nor we need a better way to notify people that this breaks things.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"30076","messageId":"86wt4jrdu6.fsf@blue.stonehenge.com","threadId":"6075","inReplyTo":"861wmrsstc.fsf@blue.stonehenge.com","subject":"Re: What's in git.git (stable)","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-12-22T18:21:37Z","receivedAt":"2006-12-22T18:21:37Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Randal\" == Randal L Schwartz writes:\n\nRandal> But that's not upward compatible. The default should be the old behavior,\nRandal> or we need a better way to notify people that this breaks things.\n\nNot to mention that the manpage still says:\n\n git pull, git pull origin\n Fetch the default head from the repository you cloned from and\n merge it into your current branch.\n\nSo even if I was *looking* for a change in behavior, it wasn't documented.\nNothing changed in that area in recent history.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"30077","messageId":"7vwt4jzrjb.fsf@assigned-by-dhcp.cox.net","threadId":"6075","inReplyTo":"86fyb7sv9f.fsf@blue.stonehenge.com","subject":"Re: What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-22T18:58:32Z","receivedAt":"2006-12-22T18:58:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n>>>>>> \"Randal\" == Randal L Schwartz writes:\n>>>>>> \"Junio\" == Junio C Hamano writes:\n> Junio> git-pull: refuse default merge without branch.*.merge\n>\n> Randal> Argh. How do I get back the old behavior?\n> Randal> \"git-pull origin\" doesn't seem to be enough.\n>\n> Randal> You just broke a bunch of automated scripts for me.\n>\n> Ahh, it's \"git-pull . origin\".\n>\n> Maybe a bit more warning for non-upward-compatible changes though, please.\n>\n> Or maybe we should presume everything is non-upward compatible? I didn't\n> think a naked \"git-pull\" was that out of the ordinary.\n\nThings are supposed to be upward compatible, but this round\nuntil v1.5.0 some things may not be when it is justifiably an\nimprovement. For example, we've already made 'separate remote'\nnot only the default but the only layout 'git clone' produces.\nI cannot think of others offhand, but I am reasonably certain\nthere are others. We need a \"incompatible changes\" list.\n\nThe tradtional \"pull always merges the first set of branches\"\nrule, although I was actually very much in favor of it, was\nsomething that was hated by everybody.\n\nIt was said that people had lot of trouble after doing \"git pull\norigin\" without any refspecs (\"git pull\" without any argument\ndefaults to 'origin' which is backward compatible, if you do not\nhave branch.*.remote, so that form has the same issues), when on\na branch other than the 'master' branch. \"merges the same first\nset of branches no matter which branch you are on\" was the rule,\nbut people did not want to merge the ones they usually merge to\ntheir 'master' but wanted some other branch merged.\n\"branch.*.merge\" can be used to specify this, but if you do not\nhave need for this \"merge different branches depending on which\nbranch I am on\", you do not have to use it. Without\n\"branch.*.merge\" for the current branch, we are still backward\ncompatible and follow the \"first set of branches\" rule.\n\nThe real trouble is that some people further argued that pulling\nwithout 'branch.*.merge' when you might not want to follow the\n\"first set of branches\" rule might be a newbie mistake and\nshould be warned and forbidden. The commit that broke you was\nan attempt for that behaviour. I think that newbie protection\nintent is good, but the execution was obviously not.\n\nWhat I have on 'master' has a little fixup to use 'first set of\nbranches' rule when the fetch gets only one branch without\ncomplaining. I am still not happy with that either, and at this\npoint I am not sure if there is a good compromise that does not\nbreak existing setup while offering the newbie protection.\n\nPossibilities:\n\n (1) Forget about that \"protection\" business. If you do not\n want mistakes, use 'branch.*.merge' but otherwise we will\n continue to follow the good old \"first set of branches\"\n rule.\n\n (2) A slight variant of the above; do the \"protection\" only\n when 'branch.*.merge' is defined for _any_ of the branches,\n not just the current branch.\n\n (3) A further variant; do not do the above \"protection\" if the\n current branch is 'master' (this further makes 'master'\n special, which some people may hate).\n"},{"id":"30079","messageId":"Pine.LNX.4.63.0612221949490.19693@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6075","inReplyTo":"861wmrsstc.fsf@blue.stonehenge.com","subject":"Re: What's in git.git (stable)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-22T19:21:02Z","receivedAt":"2006-12-22T19:21:02Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 22 Dec 2006, Randal L. Schwartz wrote:\n\n> >>>>> \"Johannes\" == Johannes Schindelin \n> >>>>> writes:\n> \n> >> Ahh, it's \"git-pull . origin\".\n> \n> Johannes> This is just a merge, not a real pull (it leaves out the fetch \n> Johannes> part).\n> \n> OK, so what does what a naked \"git-pull\" used to do before, which was \n> \"fetch origin, then pull it into the current branch\"?\n\n$ git repo-config branch.xyz.remote origin\n$ git repo-config branch.xyz.merge refs/heads/\n\n> Johannes> So, for each branch (e.g. \"xyz\") for which you have a \n> Johannes> preferred upstream (e.g. remote \"linus\" with branch\n> Johannes> \"master\"), say\n> \n> Johannes> \t$ git repo-config branch.xyz.remote linus\n> Johannes> \t$ git repo-config branch.xyz.merge refs/heads/master\n> \n> But that's not upward compatible. The default should be the old \n> behavior, or we need a better way to notify people that this breaks \n> things.\n\nAFAIK it is not in maint. Not even in 1.4.4.3. So, you got it with master.\n\nSo, TFA should have been in a message \"What's in git (stable)\". \nAlas, the commit a71fb0a1: \"git-pull: refuse default merge without \nbranch.*.merge\" was merged _after_ the latest announcement.\n\nHOWEVER, it has been in \"What's cooking in git (topics)\".\n\nHaving said that, we could (at least for some time) print a big red \nwarning for the specific case of \"git pull\" meaning \"git pull origin \n\" that this will GO AWAY SOON.\n\nOf course, you would not see it. Only your script.\n\nBTW I would _never_ allow a script to rely on such a DWIM feature.\n\nCiao,\nDscho\n"},{"id":"30086","messageId":"emhdir$he9$1@sea.gmane.org","threadId":"6075","inReplyTo":"7vwt4jzrjb.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-22T20:04:09Z","receivedAt":"2006-12-22T20:04:09Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\n\nJunio C Hamano wrote:\n\n> Possibilities:\n> \n>  (1) Forget about that \"protection\" business.  If you do not\n>      want mistakes, use 'branch.*.merge' but otherwise we will\n>      continue to follow the good old \"first set of branches\"\n>      rule.\n\nWhat about marking default branch to merge explicitely using\n\"Merge:\" in remotes/, or remote..merge?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"30089","messageId":"7virg3zo1k.fsf@assigned-by-dhcp.cox.net","threadId":"6075","inReplyTo":"Pine.LNX.4.63.0612221949490.19693@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-22T20:13:59Z","receivedAt":"2006-12-22T20:13:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> HOWEVER, it has been in \"What's cooking in git (topics)\".\n>\n> Having said that, we could (at least for some time) print a big red \n> warning for the specific case of \"git pull\" meaning \"git pull origin \n> \" that this will GO AWAY SOON.\n>\n> Of course, you would not see it. Only your script.\n>\n> BTW I would _never_ allow a script to rely on such a DWIM feature.\n\nThat's too strong a statement. It is not DWIM but has been a\nlongstanding rule to use \"the first set of branches\" for the\nmerge. We've merged the first set of branches since day one,\nand even after branch.*.merge we've done so unless you do not\nhave such configuration.\n\nThe complaint (or \"newbie protection\") was a backward\nincompatible change, and it was executed poorly. So my\napologies go to Merlyn.\n\nWhile many \"new features\" can be done in backward compatible\nway, any \"newbie protection\" can break existing practices --\nbecause the whole point of \"protection\" is to forbid what once\nwas allowed only because we did not use to check. And when we\nhave something that we check now that we did not check before,\nthat by definition will not be backward compatible.\n\nSome backward incompatibilities are more justfiable than others.\nFor example, we recently changed \"git add\" without argument not\nto do anything. It used to have the same effect as \"git add .\",\nbut (1) adding all files in a working tree is a rare event, (2)\njust a single dot is not hard to type, (3) without argument you\nwill get a response \"not doing anything\". On the other hand,\ndoing \"git add\" without argument by mistake and ending up with\nthe index with many unwanted files is more painful and more\nlikely to hapen -- it is more valuable to protect users against\nit than saving the two keysrokes. That's why I think that\nchange is a justified improvement.\n\nI do not think this \"merge complaint\", at least in the form that\nlived on 'master', is justifiable. The first one that was\nmerged from the topic made it a requirement to have the\nbranch.*.merge configuration when you do not give explicit\nrefspecs on the command line, which was just outright WRONG.\nThe one currently on the public repository says if the fetch\nended up getting only one branch then not having branch.*.merge\nis Ok, which arguably is an improvement, but I do not think is\ngood enough. I mentioned other possibilities in my earlier\nmessage.\n\nI also personally think that it is not as clear cut as the \"git\nadd\" case that \"the first set of branches\" rule is wrong, but\nthe trouble I caused to Merlyn and Luben primarily comes from\nthe check to trigger \"newbie protection\", not from what the\nprotection is trying to do.\n"},{"id":"30091","messageId":"7vejqrznwo.fsf@assigned-by-dhcp.cox.net","threadId":"6075","inReplyTo":"emhdir$he9$1@sea.gmane.org","subject":"Re: What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-22T20:16:55Z","receivedAt":"2006-12-22T20:16:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> \n>\n> Junio C Hamano wrote:\n>\n>> Possibilities:\n>> \n>>  (1) Forget about that \"protection\" business.  If you do not\n>>      want mistakes, use 'branch.*.merge' but otherwise we will\n>>      continue to follow the good old \"first set of branches\"\n>>      rule.\n>\n> What about marking default branch to merge explicitely using\n> \"Merge:\" in remotes/, or remote..merge?\n\nSorry, how is that an improvement over the current branch.*.merge?\nand how would that help not breaking existing setups?\n"},{"id":"30092","messageId":"458C3E65.4090807@gmail.com","threadId":"6075","inReplyTo":"7vodpw46zj.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable)","fromName":"Quy Tonthat","fromEmail":"qtonthat@gmail.com","sentAt":"2006-12-22T20:21:57Z","receivedAt":"2006-12-22T20:21:57Z","isPatch":false,"sender":{"key":"qtonthat@gmail.com","avatar":null},"body":"Junio C Hamano wrote:\n> * The 'master' branch has these since the last announcement.\n[...]\n> \n> Quy Tonthat (2):\n> ...\n> Documentation/git-branch: new -r to delete remote-tracking branches.\n> \nThis one is not there on the 'master' branch.\nQuy\n"},{"id":"30096","messageId":"Pine.LNX.4.63.0612222141060.19693@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6075","inReplyTo":"7virg3zo1k.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-22T20:44:34Z","receivedAt":"2006-12-22T20:44:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 22 Dec 2006, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > HOWEVER, it has been in \"What's cooking in git (topics)\".\n> >\n> > Having said that, we could (at least for some time) print a big red \n> > warning for the specific case of \"git pull\" meaning \"git pull origin \n> > \" that this will GO AWAY SOON.\n> >\n> > Of course, you would not see it. Only your script.\n> >\n> > BTW I would _never_ allow a script to rely on such a DWIM feature.\n> \n> That's too strong a statement. It is not DWIM but has been a\n> longstanding rule to use \"the first set of branches\" for the\n> merge. We've merged the first set of branches since day one,\n> and even after branch.*.merge we've done so unless you do not\n> have such configuration.\n\nOkay, I have been wrong. My sincere apologies.\n\nSo, if I understand your option (2) correctly, it complains _only_ if \nthere is at least one branch.*.merge in the config, but not for the \ncurrent branch?\n\nI think that would safeguard the existing repositories _and_ the new ones, \nbecause git-clone sets them up with such an entry to begin with.\n\nIf that behaviour was meant by (2), I am all for it.\n\nCiao,\nDscho\n"},{"id":"30098","messageId":"200612222156.21215.jnareb@gmail.com","threadId":"6075","inReplyTo":"7vejqrznwo.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-22T20:56:20Z","receivedAt":"2006-12-22T20:56:20Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Jakub Narebski writes:\n> \n>> \n>>\n>> Junio C Hamano wrote:\n>>\n>>> Possibilities:\n>>> \n>>>  (1) Forget about that \"protection\" business.  If you do not\n>>>      want mistakes, use 'branch.*.merge' but otherwise we will\n>>>      continue to follow the good old \"first set of branches\"\n>>>      rule.\n>>\n>> What about marking default branch to merge explicitely using\n>> \"Merge:\" in remotes/, or remote..merge?\n> \n> Sorry, how is that an improvement over the current branch.*.merge?\n> and how would that help not breaking existing setups?\n\nI meant that in addition to forgetting about \"protection\" business.\nThis would be intermediate improvement over old behavior, marking\nclearly which is default branch to merge (with first branch still\nbeing default, and perhaps error out if there is _only_ wildcard\nPull:/fetch line/variable; the branches marked with + are ineligible\nas candidate for merge with \"first branch being default branch to\nmerge\" default).\n\nPerhaps make \"protection\" business optional, default to on for\nnew users?\n-- \nJakub Narebski\nPoland\n"},{"id":"30107","messageId":"7vac1fy5ae.fsf@assigned-by-dhcp.cox.net","threadId":"6075","inReplyTo":"Pine.LNX.4.63.0612222141060.19693@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-22T21:44:25Z","receivedAt":"2006-12-22T21:44:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> So, if I understand your option (2) correctly, it complains _only_ if \n> there is at least one branch.*.merge in the config, but not for the \n> current branch?\n>\n> I think that would safeguard the existing repositories _and_ the new ones, \n> because git-clone sets them up with such an entry to begin with.\n>\n> If that behaviour was meant by (2), I am all for it.\n\nI am not quite sure about that. An old timer would work in a\nnewly cloned repository after all, and what this \"newbie\nprotection\" is breaking is not existing repositories but\nexpectation from existing users.\n\nIn any case, here is a patch for discussion.\n\ndiff --git a/git-parse-remote.sh b/git-parse-remote.sh\nindex f163821..b4d071b 100755\n--- a/git-parse-remote.sh\n+++ b/git-parse-remote.sh\n@@ -145,10 +145,22 @@ canon_refs_list_for_fetch () {\n \t\t\tmerge_branches=$(git-repo-config \\\n \t\t\t --get-all \"branch.${curr_branch}.merge\")\n \t\tfi\n-\t\t# If we are fetching only one branch, then first branch\n-\t\t# is the only thing that makes sense to merge anyway,\n-\t\t# so there is no point refusing that traditional rule.\n-\t\tif test $# != 1 && test \"z$merge_branches\" = z\n+\t\tif test \"z$merge_branches\" = z &&\n+\t\t\t# If we are fetching only one branch, then\n+\t\t\t# first branch is the only thing that makes\n+\t\t\t# sense to merge anyway, so there is no point\n+\t\t\t# refusing that traditional rule.\n+\t\t\ttest $# != 1 &&\n+\n+\t\t\t# Also, old timers have been happily working\n+\t\t\t# with the first branch rule without having\n+\t\t\t# any branch.*.merge configuration, so if\n+\t\t\t# there is none, do not bother with this\n+\t\t\t# \"newbie protection\". A newly cloned\n+\t\t\t# repository would have branch.master.merge\n+\t\t\t# set for it.\n+\t\t\tgit repo-config --get-regexp \\\n+\t\t\t\t'^branch\\..*\\.merge$' >/dev/null\n \t\tthen\n \t\t\tmerge_branches=..this..would..never..match..\n \t\tfi\n"},{"id":"30108","messageId":"7v3b77y52j.fsf@assigned-by-dhcp.cox.net","threadId":"6075","inReplyTo":"200612222156.21215.jnareb@gmail.com","subject":"Re: What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-22T21:49:08Z","receivedAt":"2006-12-22T21:49:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Junio C Hamano wrote:\n> ...\n>>>> Possibilities:\n>>>> \n>>>>  (1) Forget about that \"protection\" business.  If you do not\n>>>>      want mistakes, use 'branch.*.merge' but otherwise we will\n>>>>      continue to follow the good old \"first set of branches\"\n>>>>      rule.\n>>>\n>>> What about marking default branch to merge explicitely using\n>>> \"Merge:\" in remotes/, or remote..merge?\n>> \n>> Sorry, how is that an improvement over the current branch.*.merge?\n>> and how would that help not breaking existing setups?\n>\n> I meant that in addition to forgetting about \"protection\" business.\n> This would be intermediate improvement over old behavior.\n\nI do not think so. It does not talk about \"when on my local\nbranch X do this\", and applies to all pulls from the named\nremote. Then longstanding rule of merging the first set of\nbranches is just fine and as expressive. You see them the first\nin the list, and you already know they somehow matter more.\n\nOn the other hand, I think Santi's branch.*.merge (done in\ncommit 5372806a) _was_ a real improvement.\n\n> Perhaps make \"protection\" business optional, default to on for\n> new users?\n\nNow the question is how you would tell \"new users\".\n\nThe possibility (2) is not even good enough, because even old\ntimers work in a newly cloned repositories.\n"},{"id":"30313","messageId":"418215.90592.qm@web31809.mail.mud.yahoo.com","threadId":"6075","inReplyTo":"7vac1fy5ae.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable)","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-12-26T20:25:37Z","receivedAt":"2006-12-26T20:25:37Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Junio C Hamano wrote:\n> I am not quite sure about that. An old timer would work in a\n> newly cloned repository after all, and what this \"newbie\n> protection\" is breaking is not existing repositories but\n> expectation from existing users.\n\nHmm, \"newbie protection\" doesn't sound good. It sounds like\n\"screw the old-timers and let's change well-established workflow\".\n\nThe expectation is that one always pulls into origin, merges\ninto master, and maybe checks out master to see the remote\nmaster. From then on, they decide what, where and how to\nmerge (from) master into any local branches, and then\neventually export local branches to the public.\n\nThe \"^branch.\\.*\" options seem to be counter-intuitive to\n1) git's behavor and 2) see above.\n\nGenerally \"pulling\" a remote master in a local branch, without\nthe local \"origin+master\" being fast-forwarded/merged should be\nconsidered non-git-conformant behavior. Assuming that the local\nbranch is a branch of master/origin, which is almost ever the case.\n\n> In any case, here is a patch for discussion.\n> \n> diff --git a/git-parse-remote.sh b/git-parse-remote.sh\n> index f163821..b4d071b 100755\n> --- a/git-parse-remote.sh\n> +++ b/git-parse-remote.sh\n> @@ -145,10 +145,22 @@ canon_refs_list_for_fetch () {\n> \t\t\tmerge_branches=$(git-repo-config \\\n> \t\t\t --get-all \"branch.${curr_branch}.merge\")\n> \t\tfi\n> -\t\t# If we are fetching only one branch, then first branch\n> -\t\t# is the only thing that makes sense to merge anyway,\n> -\t\t# so there is no point refusing that traditional rule.\n> -\t\tif test $# != 1 && test \"z$merge_branches\" = z\n> +\t\tif test \"z$merge_branches\" = z &&\n> +\t\t\t# If we are fetching only one branch, then\n> +\t\t\t# first branch is the only thing that makes\n> +\t\t\t# sense to merge anyway, so there is no point\n> +\t\t\t# refusing that traditional rule.\n> +\t\t\ttest $# != 1 &&\n> +\n> +\t\t\t# Also, old timers have been happily working\n> +\t\t\t# with the first branch rule without having\n> +\t\t\t# any branch.*.merge configuration, so if\n> +\t\t\t# there is none, do not bother with this\n> +\t\t\t# \"newbie protection\". A newly cloned\n> +\t\t\t# repository would have branch.master.merge\n> +\t\t\t# set for it.\n\nIt should probably have branch.*.remote _and_ branch.*.merge set\nfor completeness. Or we should remove the branch.* options\nfrom git-config and leave this up to porcelains.\n\n> +\t\t\tgit repo-config --get-regexp \\\n> +\t\t\t\t'^branch\\..*\\.merge$' >/dev/null\n\nHow does this \"set\" it?\n\n Luben\n\n\n> \t\tthen\n> \t\t\tmerge_branches=..this..would..never..match..\n> \t\tfi\n"},{"id":"30318","messageId":"7vd566ciwq.fsf@assigned-by-dhcp.cox.net","threadId":"6075","inReplyTo":"418215.90592.qm@web31809.mail.mud.yahoo.com","subject":"Re: What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-26T23:54:45Z","receivedAt":"2006-12-26T23:54:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov writes:\n\n>> I am not quite sure about that. An old timer would work in a\n>> newly cloned repository after all, and what this \"newbie\n>> protection\" is breaking is not existing repositories but\n>> expectation from existing users.\n>\n> Hmm, \"newbie protection\" doesn't sound good. It sounds like\n> \"screw the old-timers and let's change well-established workflow\".\n\nAs far as I am concerned, this is a topic already closed four\ndays ago with commit fb8696d9.\n\nAre you way too behind, are you rubbing it in, or am I\nhallucinating and fb8696d9 did not actually fix it?\n"},{"id":"30324","messageId":"368927.59162.qm@web31804.mail.mud.yahoo.com","threadId":"6075","inReplyTo":"7vd566ciwq.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable)","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-12-27T01:19:03Z","receivedAt":"2006-12-27T01:19:03Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Junio C Hamano wrote:\n> Luben Tuikov writes:\n> \n> >> I am not quite sure about that. An old timer would work in a\n> >> newly cloned repository after all, and what this \"newbie\n> >> protection\" is breaking is not existing repositories but\n> >> expectation from existing users.\n> >\n> > Hmm, \"newbie protection\" doesn't sound good. It sounds like\n> > \"screw the old-timers and let's change well-established workflow\".\n> \n> As far as I am concerned, this is a topic already closed four\n> days ago with commit fb8696d9.\n> \n> Are you way too behind, are you rubbing it in, or am I\n> hallucinating and fb8696d9 did not actually fix it?\n\nI'm behind. I'll pull and take a look at that commit.\n\n Luben\n"},{"id":"30325","messageId":"7vslf2axvj.fsf@assigned-by-dhcp.cox.net","threadId":"6075","inReplyTo":"368927.59162.qm@web31804.mail.mud.yahoo.com","subject":"Re: What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-27T02:14:24Z","receivedAt":"2006-12-27T02:14:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov writes:\n\n> --- Junio C Hamano wrote:\n>> Luben Tuikov writes:\n>> \n>> >> I am not quite sure about that. An old timer would work in a\n>> >> newly cloned repository after all, and what this \"newbie\n>> >> protection\" is breaking is not existing repositories but\n>> >> expectation from existing users.\n>> >\n>> > Hmm, \"newbie protection\" doesn't sound good. It sounds like\n>> > \"screw the old-timers and let's change well-established workflow\".\n>> \n>> As far as I am concerned, this is a topic already closed four\n>> days ago with commit fb8696d9.\n>> \n>> Are you way too behind, are you rubbing it in, or am I\n>> hallucinating and fb8696d9 did not actually fix it?\n>\n> I'm behind. I'll pull and take a look at that commit.\n\nThanks.\n\nAnd sorry that I sounded harsher than necessary. Between the\ntwo paragraphs, I meant to say \"... with commit fb8696d9. It\nwas a mistake, I broke existing workflows, I apologized, and the\ncommit should have fixed it\".\n"}]}