Re: Re* [GIT PULL] sh updates for 2.6.25

[Miklos Vajna <vmiklos@frugalware.org>]

[-- Attachment #1: Type: text/plain, Size: 2890 bytes --]

On Wed, Apr 16, 2008 at 12:58:54PM -0700, Junio C Hamano <gitster@pobox.com> 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 #2: Type: application/pgp-signature, Size: 197 bytes --]