On Thu, Aug 23, 2018 at 11:30:54AM -0700, Junio C Hamano wrote: > > Now here's the tricky part. I think patches 1-8 are mostly sensible. > > Yeah, nothing that made me go "Huh?" in these 8 patches. Thanks. > > > So I think there may be further opportunities for cleanup here. I'm not > > sure if we'd need to retain this behavior for git-interpret-trailers. > > AFAICT it is not documented, and I suspect is mostly historical > > accident, and not anything anybody ever wanted. > > I tend to think the behaviour was not designed but it "just happens > to work that way".
OK, so I've slept on it as promised, and looked at ignore_non_trailer() a bit more closely. It actually ignores three things: - comment blocks - "commit -v" cut lines - "Conflicts:" blocks for merges I think I could see an argument for handling the third type everywhere, if we wanted trailers to go above such a block (since they really are part of the actual commit message). Of course, we try to make those "Conflicts" blocks into comments these days. And looking at our history, I had trouble finding many examples, since most of the old merges do not have sign-offs in the first place. There are a handful with the S-o-b below the conflict block (e.g., a24a32ddb). There are even some gems like 425b139313 and a5db4b127b) where there is one sign-off above the block and one below. In our history, there's nothing more recent than 2015, which is not incredibly long after 261f315beb (merge & sequencer: turn "Conflicts:" hint into a comment, 2014-10-28). But in linux.git, I can find many examples from this year of Conflicts blocks with the signoffs afterwards. And a few with the signoffs before (e.g., ed09f6d05c). I think the current code will do the right thing either way when parsing those (if the trailers are after, we won't exclude those, but if they're before, then we'll skip over the Conflicts block). So frankly, that all makes me afraid of touching any of it. I do think it's probably doing the wrong thing in some cases, and we should probably just make a rule like "trailers always go at the bottom, end of story". But there are enough weird and historical cases, not to mention potential interactions with git-commit, that I'd be quite likely to regress some other case. So my inclination is to punt on it for now, and go with my patches 1-8, which fix an actual case that we saw in the real world, without creating other problems. I think patch 9 is not hurting anything and may later help us, but I could take or leave it. > > If we do keep it by default, then the "--no-divider" option I added in > > patch 4 should probably get a more generic name and cover this. > > Something like "--verbatim-input". > > Perhaps. Even if this is not covered, --verbatim-input would be a > good name for the option ;-) Possibly. :) What I was worried about is realizing that it's not really "verbatim", though, but rather "some mystical set of rules including nonsense like git-commit cut-lines". And so we should not over-promise with the option name. I'd also be OK to call it "verbatim" and consider it a to-be-fixed bug that it still respects these weird rules. I'm just not sure I want to spend more time digging on those weird rules now. -Peff
