On Thu, Dec 3, 2020 at 11:48 AM Sergey Organov <sorganov@xxxxxxxxx> wrote: > > Elijah Newren <newren@xxxxxxxxx> writes: > > > On Sun, Nov 8, 2020 at 1:43 PM Sergey Organov <sorganov@xxxxxxxxx> wrote: > >> > >> These patch series implement new set of options governing the diff output > >> of merge commits, all under the umbrella of the single --diff-merges=<mode> > >> option. Most of the new options being synonyms for -m/-c/--cc options, > >> there is also additional functionality provided, allowing to get the format > >> of "-p --first-parent" without change in history traversal that > >> --first-parent option causes. > >> > >> The net result of these series are the following new options: > >> > >> --diff-merges= | old equivalent > >> -----------------+---------------- > >> first-parent | --first-parent (only format implications) > >> separate | -m > >> combined | -c > >> dense-combined | --cc > > > > Interesting. I have some local patches implementing another choice, > > with the new flag --remerge-diff. This flag will cause `git show` or > > `git log` to automatically remerge the two parents in a 2-parent merge > > commit, and then diff the merge commit against that automatic merge, > > showing the result. Thus, the diff for a merge commit is likely to be > > empty if the merge was clean, and is likely to show the removal of > > conflict markers if the merge was not clean. > > > > I'm curious how it'd interact with this new option. Would it also get > > a name, e.g. --diff-merges=remerge-diff? Feels like a mouthful, but I > > can't come up with anything better. > > Maybe, --diff-merges=remerge? > > > > > Also, I'm curious how it'd interact with another option I added, named > > --remerge-diff-only. This latter option modifies revision traversal > > in that it skips octopus merges, root commits, and single parent > > commits IF no cherry-pick or revert information can be found. If it > > finds a 2-parent merge commit, it behaves like --remerge-diff. If it > > finds a 1-parent commit with cherry-pick or revert information, it'll > > do an in memory repeat of that cherry-pick (or revert) and then diff > > the actual commit against what the automatic cherry-pick would > > perform. Again, that likely means an empty diff if the automatic > > cherry-pick was clean, and showing any changes made by the user to > > complete the original cherry-pick (such as deleting conflict markers > > and picking which chunks from which side to keep) if the automatic > > cherry-pick was not clean. (I suspect --remerge-diff-only is much > > more likely to be used with `git show` than with `git log`.) Anyway, > > your changes seem to suggest that anything relating to how diffs for > > merges are handled should be documented in the same section, but > > --remerge-diff-only doesn't fit. And it'd seem odd to have > > --remerge-diff and --remerge-diff-only not show up in adjacently but > > be split into separate sections. Any ideas? > > Sounds like commits limiting option to me. I think it could be named by > its limiting behavior only, say, --remerges. Then it will imply > --diff-merges=remerge, that'd allow user to re-define diff format if she > needs to. It is commit limiting, but the focus is more on the behavioral change in how diffs are shown: * for 2-parent merges * for single-parent commits with cherry-pick or revert information and acknowledging that since it has _altered_ the normal way of showing diffs for a number of single-parent commits, that it'd be confusing to show normal diffs of unaffected commits (how would you be able to tell what type of diff you're looking at if both appear in the log?). Thus, it does commit limiting to only select commits which will make use of the new diff type. (I suspect it will be more common for folks to use the --remerge-diff-only option, or whatever we end up calling it, with `git show` where the commit limiting doesn't matter -- but I have used it with log to go looking for "evil" reverts/cherry-picks that might have occurred in history.) > I mean, it looks very similar to --first-parent to me in the ways it > could be defined/implemented. Recall that --first-parent now implies > --diff-merges=first-parent. > > [...] > > >> > >> Updates in v1: > > > > A minor point, but this should have been labelled v2. The unlabelled > > original submission is v1. > > Well, I did consider it when prepared v1, but given: > > git format-patch --reroll-count=0 > > produces [PATCH], it only sounds natural to follow with > > git format-patch --reroll-count=1 > > that produces [PATCH v1]. I didn't know about --reroll-count, I've always just seen people jump from [PATCH] to [PATCH v2]. Interesting.
