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. -Peff