Re: [PATCH] git-commit: add --verbatim to allow unstripped commit messages

On 2007.12.20 15:55:18 -0800, Linus Torvalds wrote:

On Fri, 21 Dec 2007, Alex Riesen wrote:

quoted

Yes, I afraid I need both. I use "git commit -t" almost (submission in
perforce takes careful planning) every day. I also would like to keep
the empty leading and trailing lines (perforce default GUI P4Win does
not show them, but our scripts which check the descriptions will test
the description text according to template which does have trailing
empty lines).

Hmm. I think your updated patch was pretty good, although I still think it 
could be improved a bit. In particular, thinking more about it, I think we 
have more than an "on/off" switch - we really have three cases:

 a) strip whitespace _and_ comments
 b) strip unnecessary whitespace only
 c) leave things _totally_ alone

and on top of that we also have the issue of an editor.

So my patch basically said that in the absense of an editor, we'll still 
clean up whitespace, but not comments (ie "no_edit" implies doing (b) 
rather than (b)), while your patch basically results in (c) regardless of 
whether we run an editor or not.

But that still leaves one case: do we ever want to do (b) even *if* we use 
an editor? There's another possible choice: our old behaviour of (a) in 
the presense of an editor is now gone.

Now, that last choice (ie "case (a) without an editor") is not only 
unlikely to be anything people want to do anyway, it's also easy enough to 
do by just using "git stripspace -s" on whatever non-editor thing you feed 
to "git commit", so I don't think we need to worry about that one.

But the "maybe you want to run an editor, and you _do_ want case (b)" 
sounds like a case that is not at all unlikely. I could easily see the 
case where you want to have a template that uses '#', and *despite* that 
you want to (a) allow the user to edit things _and_ (b) clean up 
whitespace too.

So I'd almost suggest you make the "--verbatim" flag a three-way switch, 
to allow "totally verbatim" (leave everything in place) and a "don't touch 
comments" (just fix up whitespace) mode.

Hmm? Does that make sense to you?

Hm, this is a bit more intrusive, but should catch most cases.

At the top of the comments in the commit message template add:
#GIT CUT HERE
(And adjust the descriptive text)

That line hopefully being uncommon enough to not affect any existing
stuff.

If that line is present, comment lines above it are kept, otherwise
they're removed. Whitespace is always fixed(?).

Results:
 - git commit -m "# Foo and bar"
   * keeps the comment, looks like the expected thing

 - git commit with editor
   * Comments that are manually added are kept
   * For the (probably seldom) case, that you want manually added
     comments to be stripped, you can still remove the "#GIT CUR HERE"
     line

 - git commit with template
   * The existing templates probably won't have a "#GIT CUT HERE" line,
     so we're backwards compatible
   * Templates that want to keep the comments can simple get a "#GIT CUT
     HERE" line at the end and Just Work, regardless of whether or not
     you forget to pass --verbatim.


Hmm?

thanks,
Björn