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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Dec 21, 2007, 00:03 UTC
Message-ID: <alpine.LFD.0.9999.0712201555570.21557@woody.linux-foundation.org>
In-Reply-To: <7vlk7plydv.fsf@gitster.siamese.dyndns.org>

On Thu, 20 Dec 2007, Junio C Hamano wrote:

Show 6 quoted lines

> 
> But I wonder if people are using a workflow like this:
> 
> 	$ cp $company_template my_message
>         $ edit my_message
>         $ git commit -F my_message

Yes. See the email I just sent to Alex.

I think that the above kind of workflow is trivial to support with the "new" semantics (ie the patch under discussion), by just rewriting that last step as

	$ git stripspace -s < my_message | git-commit -F -

so in that sense, we don't really "lose" anything, although I do agree that backwards compatibility (in case somebody actually does this!) suffers.

But for the case of actually using the built-in editing capability, we don't have that choice, so I'd argue that regardless, we should make the "--verbatim" switch be a three-way choice between (a) not touching things at all, (b) touching up just whitespace, or (c) doing the full enchilada.

And if we introduce such a flag, then I think we can make the *default* (in the absense of an explicit flag) be something like

	if (no_edit)
		default = touch_up_just_whitespace;
	else
		default = whole_enchilada

and obviously it could also be a configuration option.

That way, you could always get the existing behaviour with

	git commit --verbatim=full-enchilada -F my_message

(yeah, bad name - I'm not seriously suggesting it be called "full-enchilada", and I'm also not sure the flag should be called "--verbatim" any more if it has choices, it's more likely that we should call it something like "--cleanup={verbatim,whitespace,strip}" or something like that.

			Linus