On 2007.12.20 15:55:18 -0800, Linus Torvalds wrote:
>
>
> On Fri, 21 Dec 2007, Alex Riesen wrote:
> >
> > 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
-
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
