General question about "git range-diff"

[Robin Dos Anjos <robin_1997@hotmail.fr>]

Hi git community!

I'm a bit intimidated as this is my first message in the mailing list but I'll give it a go!
First, I'd like to say that I've been using git for years and I think it's a fantastic tool. I always learn new things about it. It's so powerful and great.

Git 2.19 introduced one of my favorite features: "git range-diff". I use it all the time. Whenever I rebase a branch, I check that I resolved conflicts correctly using a range-diff. I avoided many bugs using this strategy.

But there is a caveat. Sometimes, the rebased branch contains numerous commits and resolving conflicts commit by commit is painful. This is particularly true of long-lived feature branches with multiple people pushing to it. In this situation, I usually squash all the commits during the rebase to resolve all conflicts at once.

The problem is that I'm no longer able to use "git range-diff" after such a rebase. On one side, I have N commits and on the other, I have a single commit which is the result of squashing N commits. "git range-diff" won't let me compare such histories because it wants to match commits one by one.

There are several workarounds to this situation.

The first one is to squash all the commits before rebasing. This works because I now have a single commit on both sides. I must say I don't really like this solution because it requires creating extra git objects needlessly.

Another one is to run "a diff of diffs" manually by running multiple git commands successively. This is the approach I have chosen and that I have been using for more than a year now. I basically dump the two diffs into two files on disk, then run "git diff --no-index" to compare those diffs and finally reimplement dual coloring by hand to display it in the terminal using less. This works surprisingly well and is usually very close to what "git range-diff" would itself output. I shared my NodeJS script which does exactly that on StackOverflow if you're interested in the details: https://stackoverflow.com/questions/70416396/how-to-pretty-format-an-arbitrary-diff-of-diffs

What I like about this is that, first, I don't pollute my repository with git objects that I will never use again, but more importantly, it's very versatile. I can specify the number of commits that I want on each side, and I will get my range-diff between my two arbitrary histories.

This is a quite different strategy from what "git range-diff" offers today. While matching the commits one by one is certainly useful in many contexts, I highly appreciate being able to opt out of that and switch to a patch-based range-diff when I need it.

This is so useful to me that I'm wondering why "git range-diff" does not implement this behavior. We could imagine a flag that would make it behave as I described. Is this something that was ever considered? Are there any technical difficulties that I'm completely missing? Do you think this could be helpful to other people?

I think it would be really nice to see this in git natively, hence my message. But if that is not feasible, I will still be happy to have my script!

Thank you for reading my lengthy message and I'm looking forward to reading your insights on the matter!

Best regards,

Robin DOS ANJOS