From: Brian Malehorn <bmalehorn@gmail.com>
Date: Sun, 14 May 2017 03:39:22 GMT
Subject: Re: [PATCH 0/3] interpret-trailers + commit -v bugfix
Message-ID: <20170514033923.12870-1-bmalehorn@gmail.com>
In-Reply-To: <20170512090032.coddhlsrs6s3zm2f@sigill.intra.peff.net>


> As I said, I'm a little iffy on doing this unconditionally, but it may
> be the least-bad solution. I'd just worry about collateral damage to
> somebody who doesn't use commit.verbose, but has something scissors-like
> in their commit message.
> 
> If you were to switch out is_scissors_line() for checking the exact
> cut_line[] from wt-status.c, I think that would be a big improvement.
> We'd still have the possibility of a false positive, but it would be
> much less likely in practice.

Yes, you're probably right. Using is_scissors_line() was the path of
least resistance to fix my bug, but wasn't really the Right Thing.

I've made a new patch that uses the wt-status.c code to determine
scissors lines. "git interpret-trailers" now uses the same logic as
"git commit". This patch replaces the original 3.

And yeah, this is yet another heuristic in interpret-trailers aimed at
git commit messages. But it's hardly the first heuristic we've added,
and I'd say it makes more sense for interpret-trailers and commit to
parse the same format.