commit summary, --pretty=short and other tools

Hi,

I kind of shot myself in the foot with how to type proper commit messages.

The git-commit manual page reads:
  Though not required, it´s a good idea to begin the commit message with a
  single short (less than 50 character) line summarizing the change,
  followed by a blank line and then a more thorough description. 

... and I happen to not have done the "followed by a blank line" part.

Now, git log --pretty=oneline (for instance), shows me the full commit message on one line, which is not really what I would expect...

On the other hand, and that's how I got trapped into this, gitweb and gitk only display the first line, be it followed by a blank line or not.

So, IMHO, there would be 2 solutions:
- either change --pretty=oneline,short and other similar things to take
  only the first line and change the git-commit manpage (and whenever
  else this might be written)
- or change gitweb, gitk and any other tool that would only take the
  first line so that it takes the same summary as --pretty=oneline.

What do you think ?

Mike

On Mon, Sep 17, 2007 at 01:21:36PM +0200, Mike Hommey wrote:

If this isn't a published repo, you can fix it with filter-branch:

git filter-branch --msg-filter 'sed "1a "'

This was changed recently for git-log and company, but gitk and gitweb have not followed suit. Traditionally, the behavior was to take the first line. This was changed in 4234a761 to take the first paragraph. The rationale was that people without the nice one-line summaries are typically importing old histories, and the paragraph makes a much more sensible summary (as opposed to cutting off the summary in mid-sentence).

It depends on whether people like the new behavior. I think it is more sensible in every case _except_ the one you have mentioned, but your case is hopefully somewhat rare (though it just made it to the public in 1.5.3, so yours might be the first of many comments).

I do agree that it makes sense for all of the tools to be consistent.

-Peff

On Sep 17, 2007, at 1:21 PM, Mike Hommey wrote:

[...]

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).

See this thread: http://marc.info/?t=118561729500001&r=1&w=2

My opinion is that it would be better to keep the first line and never ever rewrite the commit messages.

Cheers,

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

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>

Benoit SIGOURE wrote:

I've had reason to ponder this quite a lot, as I've imported 15 repos from CVS and SVN where the commit authors did not follow the git-recommended way of doing things, but rather put everything as one paragraph, usually without linebreaks, in the commit message.

usually correct to grab the first sentence in case the empty line isn't there, so:

const char *find_commit_subject_end(const char *commit_msg)
{
	const char *dot, *paragraph_end;
	
	paragraph_end = strstr(commit_msg, "\n\n");
	dot = strchr(commit_msg, '.');
	
	return min_non_null(dot, paragraph_end); 
}

would probably get it right very nearly always.

I'll submit a patch in 3 hours when I get my lunch, unless someone beats me to it.

Hi,

On Tue, 18 Sep 2007, Andreas Ericsson wrote:

Counterexample (not even mentioning the missing handling of NULL):

http://brick.kernel.dk/git/?p=qemu.git;a=commit;h=eb66d86e295cd5a8f13221589806e15db62a62fa

And no, the responsible developer showed a strong unwillingness to adapt to better tools and workflows.

Ciao, Dscho

Johannes Schindelin wrote:

Well, pseudo code doesn't have to handle NULL's, as it never gets bad pseudo-input ;-)

Hmm, how about any interpunctuation char or newline followed by newline or the first dot?

It would cover this case and not be overly hard to code.

On Sep 18, 2007, at 12:13 PM, Johannes Schindelin wrote:

OK, look, I think this is the typical case where there is no single solution to fit all use cases. To handle this specific case, you could say "OK let's stop at punctuation symbols then". But what if my commit message is "Add namespace::member whatever."

If there is a single line followed by a blank line: it's a git-style commit message, do what was done before. Otherwise, we need some heuristic to find the relevant part of the commit message (if there is such a relevant part in the first place!).

Hi,

On Tue, 18 Sep 2007, Benoit SIGOURE wrote:

That's the current behaviour already.  And has been for a long time.

Or do we?

I was opposed to this change, since I think that there is really no way to fit all exisiting (!) repositories.

And since oneline was always only meant as a hint, it might just as well have stayed at "just one line, the first one".

Maybe you guys find a better method, such as providing a regular expression in the config or something, but let's not do another change that does not work for all cases.

Ciao, Dscho

El 18/9/2007, a las 12:27, Benoit SIGOURE escribió:

Uh, I don't think you'd stop a punctuation symbol unless it was the last non-whitespace character before the newline.

Even then, as Johannes says, "oneline" is only meant as a hint anyway, so it doesn't really matter that much.

Wincent