Thread (1 message) 1 message, 1 author, 2016-06-15

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:43:35

Benoit SIGOURE [off-list ref] writes:
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 [off-list ref]
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 [off-list ref]
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help