On Wed, Apr 16, 2008 at 12:58:54PM -0700, Junio C Hamano <gitster@xxxxxxxxx> wrote: > When one adopts the notion of "a single line at the top summarizes what > the commit is about", it is very natural to call that a "title", and > having a blank line between the title and the body to separate them also > becomes natural, and it matches how a patch is presented in email, as a > bonus, so it matches people's expectation. > > So this format is merely a convention when viewed at the "plumbing" level, > but it is more important than just a convention if you are living at the > "Porcelain" level; if you deviate from that, "Porcelain" would not work > very well for you. I understand this, my only problem is that some project does not use an empty line after the "title". Consider a commit message like: ---- Change foo to bar - this patch changes foo to bar becase of baz - ok devel1@, devel2@ ---- Given that a project uses such a commit message style, the newlines are removed when applying with git am, but the commit still has a title. > People who are used to other systems without a good history summarization > tools can and do write such log messages. People who make commits on such > systems whose commits are imported to git (perhaps even without them > knowing about it) do not have an incentive to use a short-and-clear single > line summary in each of their commits, as their system may not give a good > way to make use of the result of such a practice. That makes sense, but those commits are unlikely transferred using format-patch+am. :) > These days, format-patch was taught to use "the first paragraph" as the > summarizing first line to avoid chomping a sentence in the middle. This > change did not hurt people who use git "Porcelain", as the commit log > message for them is always "a single line summary, a blank line, and the > body". The first paragraph is the same as the first line for them. But > for commits that have a multi-line paragraph at the beginning, information > lossage is avoided this way. Now the first chunk of the message, even if > it is splattered over two physical lines, is used as the summary. I see. If I'm right, then basically the old behaviour is what I want. At least after a git reset --hard 4234a76167b12a7669dae0e6386c62e712b9dcf5^ I get the behaviour I wished. :) (Well, almost. It inserts a newline after the first line but that's far better than stripping all the newlines.) Would you accept a patch that would make this configurable? > So in short, when you use "am", it by design unfolds the "Subject: " line > and there is no bug there. "rebase" being implemented in terms of > "format-patch piped to am" does mangle the message because of this, but > if anything that is a bug in rebase, and not "am". Yes, that's an other issue. Thanks.
Attachment:
pgpQp7WAnnkTc.pgp
Description: PGP signature
