On Tue, Jul 21, 2020 at 10:17 AM Alireza <rezaxm@xxxxxxxxx> wrote: > > > If there were an option to allow git log for a merge to show the > > difference between what an automatic merge would do (complete with > > conflicts) and the end-state that was committed, then the resolution > > would become very accessible and the rest of your request would be > > moot. > > Happy to see there's already some interest to make this easier. > However, my main use case is not just to see those changes, ideally it > should be a separate commit to be easily reviewed in a PR, for > example, otherwise the reviewer must pull all changes locally, which > doesn't sound like an improvement, IMO. Well, perhaps here is where we diverge. Providing the ability in core git from the command line to make it easy to review manual user changes within a merge commit would make it so that various PR-related tools could add that capability as well. In fact, gerrit already has such a capability and has for years, so it's not even necessary for git to have any changes to get this kind of ability. In contrast, recording the automatic changes and the manual changes as separate commits is a short term workaround for a lack of a feature, but one that has some long term ramifications. In my opinion this workaround wrecks history and makes it ugly for the rest of forever. Yes, I have a strong opinion here, but it's actually a bit worse than that: if people like broken history, they can already record the merge as two commits -- so why do we need to add a separate option to facilitate breaking things? I don't like the idea of breaking things just because external tools don't yet have an ability we would like. I think the external tools should be fixed, and perhaps we could provide a base capability those tools can use to more easily implement such a feature. Just my (strongly worded) $0.02, of course. Elijah
