lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Detecting a non-empty second line in commit-msg hook


From: Vadim Zeitlin
Subject: Re: [lmi] Detecting a non-empty second line in commit-msg hook
Date: Sat, 10 Dec 2016 02:07:33 +0100

On Sat, 10 Dec 2016 00:59:27 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-12-10 00:38, Vadim Zeitlin wrote:
GC> > On Sat, 10 Dec 2016 00:22:08 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> Is git silently removing trailing blanks from commit messages?
GC> > 
GC> >  The short answer is "yes".
GC> 
GC> Thanks for the snipped explanation; I'm not intrepid enough to search
GC> the git sources myself, but I do have some chance of understanding
GC> them somewhat when given a specific citation.

 Of course, I didn't have to search the sources, it's just that for me it
was the fastest way to answer your question (it really didn't take long to
locate the interesting part going backwards from the code displaying
"Please enter the commit message" which I knew had to be somewhere because
you see it in your editor when committing). Searching the web for "git
commit whitespace" would have probably found it just as quickly, but would
there have been any fun in it...

GC> The short conclusion is that the commit-msg hook is okay as is.

 Yes, sorry for not making it clear in my response, perhaps I got carried
away a little bit by all the fun of spelunking in git sources.

GC> It doesn't matter that it fails to flag anomalous blanks that git
GC> will strip out anyway.

 But if it doesn't, e.g. because one day you want to commit a message with
lines starting with "#" and use --cleanup=verbatim, then the current hook
could still be useful (although, to be honest, I see very few reasons to
ever use --cleanup=verbatim instead of --cleanup=whitespace or
--cleanup=scissors for interactive commits).

VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]