Re: commit summary, --pretty=short and other tools

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 18, 2007, 00:24 UTC
Message-ID: <7vr6kwyg62.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <55887C88-8523-4839-8B91-236256A5E893@lrde.epita.fr>

Benoit SIGOURE <tsuna@lrde.epita.fr> writes:

Show 6 quoted lines

> I started using Git as a "better SVN client" and didn't follow this
> "good idea".  The thing, as I already pointed out on IRC, these a are
> more rules than just guidelines.  Some tools (such as rebase) enforce
> them.  That is, they rewrite commit messages.  I found this extremely
> annoying (Junio provided a patch but I don't know whether it's been
> applied, I personally use it in my Git).

Wow, ancient history.

d7f6bae28142e07e544efdab73260cf9f60ca899 (rebase: try not to munge commit log message) is what you are talking about. It is in 1.5.3.

commit d7f6bae28142e07e544efdab73260cf9f60ca899
Author: Junio C Hamano <gitster@pobox.com>
Date:   Sat Jul 28 17:57:25 2007 -0700

    rebase: try not to munge commit log message

    This makes rebase/am keep the original commit log message
    better, even when it does not conform to "single line paragraph
    to say what it does, then explain and defend why it is a good
    change in later paragraphs" convention.

    This change is a two-edged sword.  While the earlier behaviour
    would make such commit log messages more friendly to readers who
    expect to get the birds-eye view with oneline summary formats,
    users who primarily use git as a way to interact with foreign
    SCM systems would not care much about the convenience of oneline
    git log tools, but care more about preserving their own
    convention.  This changes their commits less useful to readers
    who read them with git tools while keeping them more consistent
    with the foreign SCM systems they interact with.

    Signed-off-by: Junio C Hamano <gitster@pobox.com>