Re: [PATCH 2/3] commit.c: add is_scissors_line
- Date: Fri, 12 May 2017 04:40:28 -0400
- From: Jeff King <peff@xxxxxxxx>
- Subject: Re: [PATCH 2/3] commit.c: add is_scissors_line
On Thu, May 11, 2017 at 10:03:46PM -0700, Brian Malehorn wrote:
> Move is_scissors_line to commit.c and expose it through commit.h.
> This is needed in commit.c, and mailinfo.c shouldn't really own it.
It was fine for mailinfo to own it until now, since it was the only
user. :) I think there are some unsaid bits in your rationale. Perhaps
Subject: mailinfo: make is_scissors_line() public
We parse scissors lines only when looking at emails, and thus the
parsing function has always lived in mailinfo.c. However, we also
generate scissors lines as part of "git commit -v". We should be able
to reuse the same function to parse them.
Once public, it doesn't really belong in mailinfo.c anymore. A better
place is commit.c because...[I had trouble filling this in; it's really
_not_ about commits in particular, but rather about the in-editor
representation of the commit message used by git-commit].
Thinking on it more, though...are the scissors lines generated by "-v"
really the same as the ones parsed by mailinfo? In the case of mailinfo,
we are parsing an externally generated string according to a heuristic
microformat. But with "commit -v", we are the ones who wrote the cut
line in the first place. Shouldn't we be a bit more picky and make sure
we parse the exact same cut line?
And indeed, we _do_ actually have to parse these cut lines already, when
we read the commit message back in. The code is in
wt_status_truncate_message_at_cut_line(), and it does do an exact match.
We should probably be using that rather than making the mailinfo