Keep order of selection when comparing commits

[ghost]

When comparing commit 1 against 4 or 4 against 1, it makes no difference in git graph.
But I think the additions and deletions has to be swapped.
Furthermore on second image: The selection where the file list is placed at puts the user in mind that that this is now the point of view. So I would assume "View File at this Revision" would give the the file version from 4 but is gives that one from 1.
Very misleading.

[mhutchie]

Hi @kt-unzner,

This is actually by design - regardless of the order you select two commits, the comparison is always from the oldest commit to the newest commit (both your screenshots show this with "Displaying all changes from c38ee566... to a32bcc5d..." on the left hand side).

When I tested the approach you've mentioned, and the current solution, the majority of users instinctively opened the commit comparison by first clicking on the newer commit, and then control-clicking on the older commit to compare with it. If the commit order isn't normalised, this would be the "reverse diff", and displays files that were added as deleted, and deleted as added. This really confused a lot of users, so I decided that it was best to always normalise the from->to order of commit comparisons. This behaviour is also consistent with numerous other popular Git UI's - so I don't think the current behaviour in Git Graph is abnormal.

When running "View File at this Revision" in the Commit Comparison View, it uses the revision of the newest commit so that all of the differences displayed in the Commit Comparison View are included in the revision of the file that is viewed. In contrast, if it used the revision of the oldest commit, it would mean that none of the differences displayed in the Commit Comparison View would be included in the revision of the file that is viewed - which is pretty useless in the context of a commit comparison.

I definitely understand that there is some room for misinterpretation with the inline Commit Comparison View, however it's an unavoidable trade-off that had to be made to allow it to be inline. Whenever I implement new features for Git Graph (including the Commit Details / Comparison View), I always get feedback from users to ensure that any trade-offs are carefully considered. There is the Commit Details View > Location extension setting that allows you to dock the view to the bottom of the Git Graph View - you might prefer it instead of the include view.

I'll close this feature request as the current implementation is by design, and was preferred by the majority of users that I tested it with. If there is a significant change in user preference in the future, I'd happily re-open this request and implement it.

[ghost]

This behaviour is also consistent with numerous other popular Git UI's - so I don't think the current behaviour in Git Graph is abnormal.

Git Extensions and the VSCode GitLens extension takes care of the order of selection for example...

There is the Commit Details View > Location extension setting that allows you to dock the view to the bottom of the Git Graph View - you might prefer it instead of the include view.

Ah nice that removes the room for the misinterpretation. I think that should be the default option.
You could also align the file list always at the newest commit regardless of the order of selection. What do you think?

[mhutchie]

You could also align the file list always at the newest commit regardless of the order of selection. What do you think?

I had experimented with this when I first implemented it, and found numerous reasons that in practice made it clunky and less than ideal compared to the solution that’s currently implemented.