View diff of diffs (range-diff)

[ackvf]

Describe the feature that you'd like Display a diff of changes introduced in two commits ignoring all intermediary commits.

• https://stackoverflow.com/questions/1191282/how-to-see-the-changes-between-two-commits-without-commits-in-between/52820480#52820480
• https://stackoverflow.com/questions/52323008/can-somebody-explain-the-usage-of-git-range-diff

git range-diff A~1..A A'~1..A'

Where A is the original commit, A' is rebased commit. and ~1 means parent of said commit, which results in the changeset of just one commit (from parent to current commit = 1 set of changes).

Additional context (optional) I have an old commit A with changes to files a, b, c. A target branch has several commits (B, K, X) touching files b, k, l, m, x, y, z I rebase the commit A onto latest target brach, resolve conflicts to file b and make last minute adjustments to file c, which results in commit A'.

Now I want to compare the changes between A and A', but ignore all changes from intermediary commits B, K, X.

Currently: Displays all changes between two commits.

Expected: Only displays changes in related files.

qwerty@QWERTY-XPS9310:~/xrepos/xxx/aaa$ git range-diff d37e8f26..e4e0a1d5 3a0e633d..cd75d971
1:  e4e0a1d57 ! 1:  cd75d9717 Add Avatar element (#560)
    @@ plugins/aaa-element-avatar/package.json (new)
     +    "testEnvironment": "jsdom"
     +  },
     +  "license": "UNLICENSED",
-    +  "name": "@xxx/aaa-element-avatar",
+    +  "name": "@xxx/aaa-element-avatarz",
     +  "publishConfig": {
     +    "registry": "https://npm.pkg.github.com",
     +    "scope": "xxx"

Note that this practically compares just two commits, but a range can be arbitrary. To support this, there would have to be a new mechanism to select a range of commits

Possible solution:

Currently after selecting one commit and then holding CTRL, additional commit can be selected for the diff.

Solution 1) With the "range-diff" or "diff of diffs" option enabled in settings or via a tiny checkbox visible in the currently displayed diff view, the user will be allowed to choose 4 commits in sequence: 1) A 2) B 3) C 4) D

resulting in git range-diff A..B C..D

Solution 2) Introduce new keyboard modifier for said commits 1) normal click chooses A 2) CTRL + click chooses B 3) SHIFT + click chooses C 4) ALT + click chooses D

Solution 3) This is similar to how Google Spreadsheet does it or even File Explorer under Windows, where CTRL can be used to start subsequent groups. 1) A: normal click 2) B: SHIFT + click (shift denotes range select) 3) C: CTRL + click (ctrl denotes new group) 4) D: CTRL + SHIFT + click (shift (while ctrl) denotes range select in latest group)

[phil294]

Coming from here: This is a great idea and I particularly like your solution 3, it feels very natural. However, wouldn't Click+Shift-Clicking a range of commits possibly also select commits from entirely unrelated branches? In Windows file explorer, this works fine because there is only one column of files. But in a graph scenario, things are different. And having shift-click logic instead be branch-related also doesn't sound like a good idea, because this limits other potential uses of multi-commit actions such as cherry-picking. So I guess the user would have to be very careful in which commits they select, and the range diff feasability determination algorithm couldn't be based on the visual appearance of the selection but instead needs to determine if the selection can be divided into two groups that consist of mutually exclusive yet individually coherently consecutive commits, making things rather less intuitive again. ...right??

[walker-zheng]

@phil294 for GitLG, maybe we need a new feature: filter branches and order by topo, firstly git log --graph --oneline --date=iso-local --pretty={EXT_FORMAT} -n 15000 --skip=0 --branches='*release-hello*' --tags='*HELLO*' --first-parent --color=never --date-order --author-date-order --topo-order

Coming from here: This is a great idea and I particularly like your solution 3, it feels very natural. However, wouldn't Click+Shift-Clicking a range of commits possibly also select commits from entirely unrelated branches? In Windows file explorer, this works fine because there is only one column of files. But in a graph scenario, things are different. And having shift-click logic instead be branch-related also doesn't sound like a good idea, because this limits other potential uses of multi-commit actions such as cherry-picking. So I guess the user would have to be very careful in which commits they select, and the range diff feasability determination algorithm couldn't be based on the visual appearance of the selection but instead needs to determine if the selection can be divided into two groups that consist of mutually exclusive yet individually coherently consecutive commits, making things rather less intuitive again. ...right??

[ackvf]

... the range diff feasability determination algorithm couldn't be based on the visual appearance of the selection but instead needs to determine if the selection can be divided into two groups that consist of mutually exclusive yet individually coherently consecutive commits, making things rather less intuitive again. ...right??

Yeah, since the rangediff needs four commits, which can be visually represented as two range selections in the UI, it does seem less intuitive, because no other commit is really selected in the range selection, except the first and last commits. But maybe the range selection is a wrong UI representation in the first place, since it does make it seem that "all this in the middle" is selected, but it is in fact not.

Another problem might arise if the two selections A..D B..C overlap. Hence why the "range selection" might not be greatest idea - or it might if the two selections can be visually differentiated somehow.

Maybe a solution would be a completely new UI, which looks kinda nice even for normal diff selection in addiction to the two highlighted rows.

This is just a mockup, add some more highlights, make the commit bullets larger (to denote that they are "included"), brighter or different color, highlight the whole row, etc.

What do you think?

[phil294]

Another problem might arise if the two selections A..D B..C overlap

Is this something one might realistically want to query for?

Maybe a solution would be a completely new UI, which looks kinda nice even for normal diff selection in addiction to the two highlighted rows.

Are the two dotted purple lines the currently "selected" ones? If so, do they have the same color on purpose? And does this solve the problem of overlapping? If they both share the same commit at some point, it'll look very confusing, probably.

[ackvf]

They don't have intentionally the same colors and damn you are right that the pattern would look confusing if the selection was on the same branch, although this is something I am not really sure would happen.

      D'       ---
      |          |
      C'         |
  D   |     ---  |    overlap
  |   B'      |---    here
  C   |       |
  |   Y       |
  B   |     ---
   \ /
    X
    |
    0

If you were to choose BCD and B'C'D', a selection that highlights the whole row would create an overlap, but if you instead highlighted the lines, they would be distinct.

I don't think that it is ever practically possible or makes sense to extend the selection beyond a common parent X anyway, because you will always want to compare diff of diffs between 1) your feature branch, 2) your feature branch AFTER rebasing, to look for errors in merge or other differences.

Anyway, if there was still a potential for overlap, the dotted pattern allows to interlay different colors and still make them visible. In this case, the color of the branch would have to be made slightly different for the second selection. Maybe darken it a bit.