Web lists-archives.com

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
something like:

 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
is_scissors_line() public.