{"thread":{"id":"9891","subject":"commit summary, --pretty=short and other tools","startedAt":"2007-09-17T11:21:36Z","lastAt":"2007-09-18T11:43:09Z","messageCount":10,"participants":["Mike Hommey","Jeff King","Benoit SIGOURE","Junio C Hamano","Andreas Ericsson","Johannes Schindelin","Wincent Colaiuta"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"53295","messageId":"20070917112136.GA30201@glandium.org","threadId":"9891","inReplyTo":null,"subject":"commit summary, --pretty=short and other tools","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-09-17T11:21:36Z","receivedAt":"2007-09-17T11:21:36Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"Hi,\n\nI kind of shot myself in the foot with how to type proper commit\nmessages.\n\nThe git-commit manual page reads:\n Though not required, it´s a good idea to begin the commit message with a\n single short (less than 50 character) line summarizing the change,\n followed by a blank line and then a more thorough description. \n\n... and I happen to not have done the \"followed by a blank line\" part.\n\nNow, git log --pretty=oneline (for instance), shows me the full commit\nmessage on one line, which is not really what I would expect...\n\nOn the other hand, and that's how I got trapped into this, gitweb and\ngitk only display the first line, be it followed by a blank line or not.\n\nSo, IMHO, there would be 2 solutions:\n- either change --pretty=oneline,short and other similar things to take\n only the first line and change the git-commit manpage (and whenever\n else this might be written)\n- or change gitweb, gitk and any other tool that would only take the\n first line so that it takes the same summary as --pretty=oneline.\n\nWhat do you think ?\n\nMike\n"},{"id":"53296","messageId":"20070917114237.GA14707@coredump.intra.peff.net","threadId":"9891","inReplyTo":"20070917112136.GA30201@glandium.org","subject":"Re: commit summary, --pretty=short and other tools","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-09-17T11:42:37Z","receivedAt":"2007-09-17T11:42:37Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Sep 17, 2007 at 01:21:36PM +0200, Mike Hommey wrote:\n\n> ... and I happen to not have done the \"followed by a blank line\" part.\n\nIf this isn't a published repo, you can fix it with filter-branch:\n\ngit filter-branch --msg-filter 'sed \"1a\n\"'\n\n> Now, git log --pretty=oneline (for instance), shows me the full commit\n> message on one line, which is not really what I would expect...\n> \n> On the other hand, and that's how I got trapped into this, gitweb and\n> gitk only display the first line, be it followed by a blank line or not.\n\nThis was changed recently for git-log and company, but gitk and gitweb\nhave not followed suit. Traditionally, the behavior was to take the\nfirst line. This was changed in 4234a761 to take the first paragraph.\nThe rationale was that people without the nice one-line summaries are\ntypically importing old histories, and the paragraph makes a much more\nsensible summary (as opposed to cutting off the summary in\nmid-sentence).\n\n> So, IMHO, there would be 2 solutions:\n> - either change --pretty=oneline,short and other similar things to take\n> only the first line and change the git-commit manpage (and whenever\n> else this might be written)\n> - or change gitweb, gitk and any other tool that would only take the\n> first line so that it takes the same summary as --pretty=oneline.\n> \n> What do you think ?\n\nIt depends on whether people like the new behavior. I think it is more\nsensible in every case _except_ the one you have mentioned, but your\ncase is hopefully somewhat rare (though it just made it to the public in\n1.5.3, so yours might be the first of many comments).\n\nI do agree that it makes sense for all of the tools to be consistent.\n\n-Peff\n"},{"id":"53371","messageId":"55887C88-8523-4839-8B91-236256A5E893@lrde.epita.fr","threadId":"9891","inReplyTo":"20070917112136.GA30201@glandium.org","subject":"Re: commit summary, --pretty=short and other tools","fromName":"Benoit SIGOURE","fromEmail":"tsuna@lrde.epita.fr","sentAt":"2007-09-17T23:52:21Z","receivedAt":"2007-09-17T23:52:21Z","isPatch":false,"sender":{"key":"tsunanet@gmail.com","avatar":"https://avatars.githubusercontent.com/u/128281?v=4"},"body":"On Sep 17, 2007, at 1:21 PM, Mike Hommey wrote:\n\n> Hi,\n>\n> I kind of shot myself in the foot with how to type proper commit\n> messages.\n>\n> The git-commit manual page reads:\n> Though not required, it´s a good idea to begin the commit message \n> with a\n> single short (less than 50 character) line summarizing the change,\n> followed by a blank line and then a more thorough description.\n>\n> ... and I happen to not have done the \"followed by a blank line\" part.\n>\n[...]\n> What do you think ?\n\nI started using Git as a \"better SVN client\" and didn't follow this \n\"good idea\". The thing, as I already pointed out on IRC, these a are \nmore rules than just guidelines. Some tools (such as rebase) enforce \nthem. That is, they rewrite commit messages. I found this extremely \nannoying (Junio provided a patch but I don't know whether it's been \napplied, I personally use it in my Git).\n\nSee this thread: http://marc.info/?t=118561729500001&r=1&w=2\n\nMy opinion is that it would be better to keep the first line and \nnever ever rewrite the commit messages.\n\nCheers,\n\n-- \nBenoit Sigoure aka Tsuna\nEPITA Research and Development Laboratory\n\n\n"},{"id":"53383","messageId":"7vr6kwyg62.fsf@gitster.siamese.dyndns.org","threadId":"9891","inReplyTo":"55887C88-8523-4839-8B91-236256A5E893@lrde.epita.fr","subject":"Re: commit summary, --pretty=short and other tools","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-18T00:24:05Z","receivedAt":"2007-09-18T00:24:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Benoit SIGOURE writes:\n\n> I started using Git as a \"better SVN client\" and didn't follow this\n> \"good idea\". The thing, as I already pointed out on IRC, these a are\n> more rules than just guidelines. Some tools (such as rebase) enforce\n> them. That is, they rewrite commit messages. I found this extremely\n> annoying (Junio provided a patch but I don't know whether it's been\n> applied, I personally use it in my Git).\n\nWow, ancient history.\n\nd7f6bae28142e07e544efdab73260cf9f60ca899 (rebase: try not to\nmunge commit log message) is what you are talking about. It is\nin 1.5.3.\n\ncommit d7f6bae28142e07e544efdab73260cf9f60ca899\nAuthor: Junio C Hamano \nDate: Sat Jul 28 17:57:25 2007 -0700\n\n rebase: try not to munge commit log message\n\n This makes rebase/am keep the original commit log message\n better, even when it does not conform to \"single line paragraph\n to say what it does, then explain and defend why it is a good\n change in later paragraphs\" convention.\n\n This change is a two-edged sword. While the earlier behaviour\n would make such commit log messages more friendly to readers who\n expect to get the birds-eye view with oneline summary formats,\n users who primarily use git as a way to interact with foreign\n SCM systems would not care much about the convenience of oneline\n git log tools, but care more about preserving their own\n convention. This changes their commits less useful to readers\n who read them with git tools while keeping them more consistent\n with the foreign SCM systems they interact with.\n\n Signed-off-by: Junio C Hamano \n"},{"id":"53401","messageId":"46EF7BF7.3070107@op5.se","threadId":"9891","inReplyTo":"55887C88-8523-4839-8B91-236256A5E893@lrde.epita.fr","subject":"Re: commit summary, --pretty=short and other tools","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-09-18T07:19:19Z","receivedAt":"2007-09-18T07:19:19Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Benoit SIGOURE wrote:\n> \n> My opinion is that it would be better to keep the first line and never \n> ever rewrite the commit messages.\n> \n\nI've had reason to ponder this quite a lot, as I've imported 15 repos from\nCVS and SVN where the commit authors did not follow the git-recommended way\nof doing things, but rather put everything as one paragraph, usually without\nlinebreaks, in the commit message.\n\n>From what I've read from those rather horrid commit-messages so far, it's\nusually correct to grab the first sentence in case the empty line isn't\nthere, so:\n\nconst char *find_commit_subject_end(const char *commit_msg)\n{\n\tconst char *dot, *paragraph_end;\n\t\n\tparagraph_end = strstr(commit_msg, \"\\n\\n\");\n\tdot = strchr(commit_msg, '.');\n\t\n\treturn min_non_null(dot, paragraph_end); \n}\n\nwould probably get it right very nearly always.\n\nI'll submit a patch in 3 hours when I get my lunch, unless someone\nbeats me to it.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"53438","messageId":"Pine.LNX.4.64.0709181109130.28586@racer.site","threadId":"9891","inReplyTo":"46EF7BF7.3070107@op5.se","subject":"Re: commit summary, --pretty=short and other tools","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-18T10:13:46Z","receivedAt":"2007-09-18T10:13:46Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 18 Sep 2007, Andreas Ericsson wrote:\n\n> const char *find_commit_subject_end(const char *commit_msg)\n> {\n> \tconst char *dot, *paragraph_end;\n> \t\tparagraph_end = strstr(commit_msg, \"\\n\\n\");\n> \tdot = strchr(commit_msg, '.');\n> \t\treturn min_non_null(dot, paragraph_end); }\n> \n> would probably get it right very nearly always.\n\nCounterexample (not even mentioning the missing handling of NULL):\n\nhttp://brick.kernel.dk/git/?p=qemu.git;a=commit;h=eb66d86e295cd5a8f13221589806e15db62a62fa\n\nAnd no, the responsible developer showed a strong unwillingness to adapt \nto better tools and workflows.\n\nCiao,\nDscho\n"},{"id":"53441","messageId":"46EFA73E.9080807@op5.se","threadId":"9891","inReplyTo":"Pine.LNX.4.64.0709181109130.28586@racer.site","subject":"Re: commit summary, --pretty=short and other tools","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-09-18T10:23:58Z","receivedAt":"2007-09-18T10:23:58Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Tue, 18 Sep 2007, Andreas Ericsson wrote:\n> \n>> const char *find_commit_subject_end(const char *commit_msg)\n>> {\n>> \tconst char *dot, *paragraph_end;\n>> \t\tparagraph_end = strstr(commit_msg, \"\\n\\n\");\n>> \tdot = strchr(commit_msg, '.');\n>> \t\treturn min_non_null(dot, paragraph_end); }\n>>\n>> would probably get it right very nearly always.\n> \n> Counterexample (not even mentioning the missing handling of NULL):\n> \n\nWell, pseudo code doesn't have to handle NULL's, as it never gets bad\npseudo-input ;-)\n\n> http://brick.kernel.dk/git/?p=qemu.git;a=commit;h=eb66d86e295cd5a8f13221589806e15db62a62fa\n> \n> And no, the responsible developer showed a strong unwillingness to adapt \n> to better tools and workflows.\n> \n\nHmm, how about any interpunctuation char or newline followed by newline or\nthe first dot?\n\nIt would cover this case and not be overly hard to code.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"53442","messageId":"CEE6032F-39FB-42D8-A57A-671E4E0875C7@lrde.epita.fr","threadId":"9891","inReplyTo":"Pine.LNX.4.64.0709181109130.28586@racer.site","subject":"Re: commit summary, --pretty=short and other tools","fromName":"Benoit SIGOURE","fromEmail":"tsuna@lrde.epita.fr","sentAt":"2007-09-18T10:27:14Z","receivedAt":"2007-09-18T10:27:14Z","isPatch":false,"sender":{"key":"tsunanet@gmail.com","avatar":"https://avatars.githubusercontent.com/u/128281?v=4"},"body":"On Sep 18, 2007, at 12:13 PM, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Tue, 18 Sep 2007, Andreas Ericsson wrote:\n>\n>> const char *find_commit_subject_end(const char *commit_msg)\n>> {\n>> \tconst char *dot, *paragraph_end;\n>> \t\tparagraph_end = strstr(commit_msg, \"\\n\\n\");\n>> \tdot = strchr(commit_msg, '.');\n>> \t\treturn min_non_null(dot, paragraph_end); }\n>>\n>> would probably get it right very nearly always.\n>\n> Counterexample (not even mentioning the missing handling of NULL):\n>\n> http://brick.kernel.dk/git/? \n> p=qemu.git;a=commit;h=eb66d86e295cd5a8f13221589806e15db62a62fa\n>\n> And no, the responsible developer showed a strong unwillingness to \n> adapt\n> to better tools and workflows.\n>\n\nOK, look, I think this is the typical case where there is no single \nsolution to fit all use cases.\nTo handle this specific case, you could say \"OK let's stop at \npunctuation symbols then\". But what if my commit message is \"Add \nnamespace::member whatever.\"\n\nIf there is a single line followed by a blank line: it's a git-style \ncommit message, do what was done before.\nOtherwise, we need some heuristic to find the relevant part of the \ncommit message (if there is such a relevant part in the first place!).\n\n-- \nBenoit Sigoure aka Tsuna\nEPITA Research and Development Laboratory\n\n\n"},{"id":"53445","messageId":"Pine.LNX.4.64.0709181153530.28586@racer.site","threadId":"9891","inReplyTo":"CEE6032F-39FB-42D8-A57A-671E4E0875C7@lrde.epita.fr","subject":"Re: commit summary, --pretty=short and other tools","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-18T10:54:11Z","receivedAt":"2007-09-18T10:54:11Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 18 Sep 2007, Benoit SIGOURE wrote:\n\n> On Sep 18, 2007, at 12:13 PM, Johannes Schindelin wrote:\n> \n> > On Tue, 18 Sep 2007, Andreas Ericsson wrote:\n> > \n> > > const char *find_commit_subject_end(const char *commit_msg)\n> > > {\n> > > \tconst char *dot, *paragraph_end;\n> > > \t\tparagraph_end = strstr(commit_msg, \"\\n\\n\");\n> > > \tdot = strchr(commit_msg, '.');\n> > > \t\treturn min_non_null(dot, paragraph_end); }\n> > > \n> > > would probably get it right very nearly always.\n> > \n> > Counterexample (not even mentioning the missing handling of NULL):\n> > \n> > http://brick.kernel.dk/git/?p=qemu.git;a=commit;h=eb66d86e295cd5a8f13221589806e15db62a62fa\n> > \n> > And no, the responsible developer showed a strong unwillingness to adapt\n> > to better tools and workflows.\n> > \n> \n> OK, look, I think this is the typical case where there is no single solution\n> to fit all use cases.\n> To handle this specific case, you could say \"OK let's stop at punctuation\n> symbols then\". But what if my commit message is \"Add namespace::member\n> whatever.\"\n> \n> If there is a single line followed by a blank line: it's a git-style commit\n> message, do what was done before.\n\nThat's the current behaviour already. And has been for a long time.\n\n> Otherwise, we need some heuristic to find the relevant part of the commit\n> message (if there is such a relevant part in the first place!).\n\nOr do we?\n\nI was opposed to this change, since I think that there is really no way to \nfit all exisiting (!) repositories.\n\nAnd since oneline was always only meant as a hint, it might just as well \nhave stayed at \"just one line, the first one\".\n\nMaybe you guys find a better method, such as providing a regular \nexpression in the config or something, but let's not do another change \nthat does not work for all cases.\n\nCiao,\nDscho\n"},{"id":"53453","messageId":"E934A152-BE07-484D-96DF-11B1BC64EB49@wincent.com","threadId":"9891","inReplyTo":"CEE6032F-39FB-42D8-A57A-671E4E0875C7@lrde.epita.fr","subject":"Re: commit summary, --pretty=short and other tools","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-09-18T11:43:09Z","receivedAt":"2007-09-18T11:43:09Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 18/9/2007, a las 12:27, Benoit SIGOURE escribió:\n\n> OK, look, I think this is the typical case where there is no single \n> solution to fit all use cases.\n> To handle this specific case, you could say \"OK let's stop at \n> punctuation symbols then\". But what if my commit message is \"Add \n> namespace::member whatever.\"\n\nUh, I don't think you'd stop a punctuation symbol unless it was the \nlast non-whitespace character before the newline.\n\nEven then, as Johannes says, \"oneline\" is only meant as a hint \nanyway, so it doesn't really matter that much.\n\nWincent\n"}]}