On Thu, 20 Dec 2007, Junio C Hamano wrote:
>
> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
