{"thread":{"id":"24427","subject":"Merge commit subjects git.git","startedAt":"2010-07-18T08:22:25Z","lastAt":"2010-07-19T17:23:06Z","messageCount":9,"participants":["Jay Soffian","Thomas Rast","Ævar Arnfjörð Bjarmason","Sverre Rabbelier","Ilari Liusvaara","Nicolas Sebrecht","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"145742","messageId":"AANLkTikavL0DH8FgFxBw7hbGLtj2tqxnP-BT77zo5FJT@mail.gmail.com","threadId":"24427","inReplyTo":null,"subject":"Merge commit subjects git.git","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-07-18T08:22:25Z","receivedAt":"2010-07-18T08:22:25Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"Color me curious, but why do the merge commit message in git.git\nsometimes look like this:\n\n Merge branch 'jn/paginate-fix'\n\nAnd other times like this:\n\n Merge remote branch 'ko/master' into jc/read-tree-cache-tree-fix\n\nI don't really see any rhyme or reason about when the \"into ...\" is\nthere and when it's not.\n\nAlso, the \"Sync with 1.7.1.1\" merges are I guess are from something like:\n\n git merge -s ours -m \"Sync with 1.7.1.1\" maint\n\n?\n\nj.\n"},{"id":"145756","messageId":"201007181733.59704.trast@student.ethz.ch","threadId":"24427","inReplyTo":"AANLkTikavL0DH8FgFxBw7hbGLtj2tqxnP-BT77zo5FJT@mail.gmail.com","subject":"Re: Merge commit subjects git.git","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2010-07-18T15:33:59Z","receivedAt":"2010-07-18T15:33:59Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jay Soffian wrote:\n> Color me curious, but why do the merge commit message in git.git\n> sometimes look like this:\n> \n> Merge branch 'jn/paginate-fix'\n> \n> And other times like this:\n> \n> Merge remote branch 'ko/master' into jc/read-tree-cache-tree-fix\n> \n> I don't really see any rhyme or reason about when the \"into ...\" is\n> there and when it's not.\n\nA merge that does not have the 'into ' bit is a merge to\nmaster:\n\nstatic void do_fmt_merge_msg_title(struct strbuf *out,\n\tconst char *current_branch) {\n[...]\n\tif (!strcmp(\"master\", current_branch))\n\t\tstrbuf_addch(out, '\\n');\n\telse\n\t\tstrbuf_addf(out, \" into %s\\n\", current_branch);\n}\n\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"145757","messageId":"AANLkTikhhjjRYPY4KWEJWUQjCw4TzhXRMvHRsaQ7BECe@mail.gmail.com","threadId":"24427","inReplyTo":"201007181733.59704.trast@student.ethz.ch","subject":"Re: Merge commit subjects git.git","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-07-18T16:18:05Z","receivedAt":"2010-07-18T16:18:05Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sun, Jul 18, 2010 at 15:33, Thomas Rast wrote:\n\n> A merge that does not have the 'into ' bit is a merge to\n> master:\n>\n> static void do_fmt_merge_msg_title(struct strbuf *out,\n>        const char *current_branch) {\n> [...]\n>        if (!strcmp(\"master\", current_branch))\n\nIs there anything in Git that records what the canonical branch is?\nE.g. perl uses \"blead\", and gets these \"into blead\" merge commits\nevery time it merges into the main branch.\n\nThe HEAD can move, so that can't be checked.\n\n(not that this is an actual problem)\n\n>                strbuf_addch(out, '\\n');\n>        else\n>                strbuf_addf(out, \" into %s\\n\", current_branch);\n> }\n"},{"id":"145758","messageId":"AANLkTinTOMxWVM9kwhIfcG44SqOjpexY-Xy6kZYkemU9@mail.gmail.com","threadId":"24427","inReplyTo":"201007181733.59704.trast@student.ethz.ch","subject":"Re: Merge commit subjects git.git","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-07-18T16:56:12Z","receivedAt":"2010-07-18T16:56:12Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Sun, Jul 18, 2010 at 10:33, Thomas Rast wrote:\n>        if (!strcmp(\"master\", current_branch))\n\nWow, I thought the only place where we gave \"master\" any special\nmeaning was in that we create it as the default branch. Can't we fix\nthis to be less hard-coded?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"145760","messageId":"AANLkTim4FxPdHsDxkRmHzJT24LnZyiv9xLUqbTUndS9T@mail.gmail.com","threadId":"24427","inReplyTo":"AANLkTinTOMxWVM9kwhIfcG44SqOjpexY-Xy6kZYkemU9@mail.gmail.com","subject":"Re: Merge commit subjects git.git","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-07-18T17:22:01Z","receivedAt":"2010-07-18T17:22:01Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sun, Jul 18, 2010 at 16:56, Sverre Rabbelier wrote:\n> Heya,\n>\n> On Sun, Jul 18, 2010 at 10:33, Thomas Rast wrote:\n>>        if (!strcmp(\"master\", current_branch))\n>\n> Wow, I thought the only place where we gave \"master\" any special\n> meaning was in that we create it as the default branch. Can't we fix\n> this to be less hard-coded?\n\nIn addition, Ilari on IRC pointed this out:\n\n < avar> What does git use to determine what branch gets checked out\n (not always master) on git clone URL?\n < Ilari> avar: HEAD\n < avar> Ah, just the HEAD of the remote, but that doesn't help after\n you've switched branches locally to find out what the main\n is..\n < Ilari> avar: Except that if you have another branch with same commit\n as the one you set to default, either of them may be selected\n (if one is 'master', then the tie is broken for it).\n\nI.e. master is also treated more magically than others when\ncloning. But I couldn't find the code that does this, so perhaps it\ndoesn't do that.\n"},{"id":"145765","messageId":"20100718180318.GA22033@LK-Perkele-V2.elisa-laajakaista.fi","threadId":"24427","inReplyTo":"AANLkTim4FxPdHsDxkRmHzJT24LnZyiv9xLUqbTUndS9T@mail.gmail.com","subject":"Re: Merge commit subjects git.git","fromName":"Ilari Liusvaara","fromEmail":"ilari.liusvaara@elisanet.fi","sentAt":"2010-07-18T18:03:18Z","receivedAt":"2010-07-18T18:03:18Z","isPatch":false,"sender":{"key":"ilari.liusvaara@elisanet.fi","avatar":null},"body":"On Sun, Jul 18, 2010 at 05:22:01PM +0000, Ævar Arnfjörð Bjarmason wrote:\n> On Sun, Jul 18, 2010 at 16:56, Sverre Rabbelier wrote:\n> >\n> > Wow, I thought the only place where we gave \"master\" any special\n> > meaning was in that we create it as the default branch. Can't we fix\n> > this to be less hard-coded?\n\nThere's yet another place as well, but its only related to obsolete pre-1.5\nstuff that has very little use anymore.\n \n> I.e. master is also treated more magically than others when\n> cloning. But I couldn't find the code that does this, so perhaps it\n> doesn't do that.\n\nIts guess_remote_head of remote.c (checked v1.7.2-rc3+). Additionally, it\nappears that if master doesn't tie for exact match, then first ref in lexical\norder is choosen (if master ties for exact match, then it is chosen).\n\nAdditionally, it appears that if exact HEAD symref information is available\n(not all protocols support that), then that is choosen with no guessing.\n\n-Ilari\n"},{"id":"145788","messageId":"20100719141057.GA13051@vidovic","threadId":"24427","inReplyTo":"AANLkTinTOMxWVM9kwhIfcG44SqOjpexY-Xy6kZYkemU9@mail.gmail.com","subject":"Re: Merge commit subjects git.git","fromName":"Nicolas Sebrecht","fromEmail":"nicolas.s.dev@gmx.fr","sentAt":"2010-07-19T14:10:57Z","receivedAt":"2010-07-19T14:10:57Z","isPatch":false,"sender":{"key":"nicolas.s.dev@gmx.fr","avatar":null},"body":"The 18/07/10, Sverre Rabbelier wrote:\n> On Sun, Jul 18, 2010 at 10:33, Thomas Rast wrote:\n> >        if (!strcmp(\"master\", current_branch))\n> \n> Wow, I thought the only place where we gave \"master\" any special\n> meaning was in that we create it as the default branch. Can't we fix\n> this to be less hard-coded?\n\nTo talk about pros and cons I wonder what would be the benefits of\nchanging this. I guess most projects probably best keeping the history\nconsistent for all the merge commit messages.\n\nI think this is more sensible than giving the same behaviour /across/\ndifferent repositories (for only which not following the \"master\"\nconvention).\n\n-- \nNicolas Sebrecht\n"},{"id":"145797","messageId":"7vpqyjph4x.fsf@alter.siamese.dyndns.org","threadId":"24427","inReplyTo":"AANLkTikavL0DH8FgFxBw7hbGLtj2tqxnP-BT77zo5FJT@mail.gmail.com","subject":"Re: Merge commit subjects git.git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-07-19T16:31:58Z","receivedAt":"2010-07-19T16:31:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jay Soffian writes:\n\n> Color me curious, but why do the merge commit message in git.git\n> sometimes look like this:\n\nThe merge messages that are autogenerated by \"git merge\" (rather, \"git\nfmt-merge-msg\") are optimized for Linus's workflow ;-) and hasn't changed\nmuch during the past 4-5 years.\n\n> Merge branch 'jn/paginate-fix'\n\nYou have _one_ primary integration branch (well, by definition, there\nshould be only one \"primary\") called \"master\", and when you merge into\nthat branch you are merging work done by a side branch that has been\ncooking. You get a terse \"Merge branch x\", \"Merge $URL\", etc. without\n\"into\".\n\n> Merge remote branch 'ko/master' into jc/read-tree-cache-tree-fix\n\nYou are not supposed to merge the integration branch into topics without a\nvery good reason. Again, because by default the tool assumes you have one\nprimary integration branch, merging into a branch that is not \"master\"\ngets \"into ...\" so that it will later stand out in the output of \"git log\"\nand \"git shortlog\".\n\nI sometimes/often add some comments explaining why I needed the merge to\nsuch a merge with \"commit --amend\" (the particular one you noticed,\njc/read-tree-cache-tree-fix, doesn't have it but I should have. The topic\nwas about fixing an ancient bug and I wanted an early conflict resolution\nbefore bringing the fix to more up-to-date codebase).\n\n> Also, the \"Sync with 1.7.1.1\" merges are I guess are from something like:\n>\n> git merge -s ours -m \"Sync with 1.7.1.1\" maint\n\nI almost never use \"-s ours\"; the only exception is when fixing mistakes,\nand \"merging all the fixes that accumulated on 'maint' to 'master'\" is\ncertainly not an example of \"fixing mistakes\".\n\nThis \"Sync with 1.7.1.1\" is an example of me using \"commit --amend\" to\nnote the exact reason why this merge of 'maint' to 'master' was made---\"to\nmake sure that we have all the fix in the last maintenance release in the\ndevelopment version\". Because the fixes to 1.7.1.1 were all cooked first\nin \"master\" and then merged to \"maint\", the result of this particular\nmerge didn't change the tree of \"master\", but that is not always the case.\n"},{"id":"145801","messageId":"AANLkTimtrGF=5k2toJo5T1oA5Q2Fp0fzDAJOw2-DR9AD@mail.gmail.com","threadId":"24427","inReplyTo":"7vpqyjph4x.fsf@alter.siamese.dyndns.org","subject":"Re: Merge commit subjects git.git","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-07-19T17:23:06Z","receivedAt":"2010-07-19T17:23:06Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Jul 19, 2010 at 12:31 PM, Junio C Hamano wrote:\n> The merge messages that are autogenerated by \"git merge\" (rather, \"git\n> fmt-merge-msg\") are optimized for Linus's workflow ;-) and hasn't changed\n> much during the past 4-5 years.\n\nAh, thank you for the explanation.\n\n> I almost never use \"-s ours\"; the only exception is when fixing mistakes,\n> and \"merging all the fixes that accumulated on 'maint' to 'master'\" is\n> certainly not an example of \"fixing mistakes\".\n>\n> This \"Sync with 1.7.1.1\" is an example of me using \"commit --amend\" to\n> note the exact reason why this merge of 'maint' to 'master' was made---\"to\n> make sure that we have all the fix in the last maintenance release in the\n> development version\".  Because the fixes to 1.7.1.1 were all cooked first\n> in \"master\" and then merged to \"maint\", the result of this particular\n> merge didn't change the tree of \"master\", but that is not always the case.\n\nCan you explain a bit about how you manage the DEF_VER variable in\nGIT-VERSION-GEN?\n\nI think I was confused not to see GIT-VERSION-GEN listed as a conflict\nin the merge message, but looking more carefully I see that the files\nwith embedded versions did indeed conflict. Do you just edit this out\nof the merge message?\n\nj.\n"}]}