General question about "git range-diff"

General question about "git range-diff"

[Robin Dos Anjos]

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

Re: General question about "git range-diff"

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2022 bytes --]

On 2023-11-02 at 18:56:39, Robin Dos Anjos wrote:
> Hi git community!

Hi,

> I'm a bit intimidated as this is my first message in the mailing list but I'll give it a go!

No reason to be intimidated.  We're very friendly here.

> 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'm not the author of range-diff, but I believe it was based on an
earlier tool named git-tbdiff[0], which had similar behaviour and
similar limitations.  My guess as to why nobody implemented a feature to
handle the squashed commits case is that typically the recommended
workflow in Git is to write small independent, logical, well-described,
bisectable commits, and squashing is not recommended because it destroys
all the work that people have put into making nice commits.

Of course, in many situations, people don't write nice commits like
that, and many commits are effectively fixup commits with very short
messages (e.g. "make it work"), sometimes containing profanity directed
at the computer, and in those environments, squashing may be a
legitimate choice.  However, it isn't typically a workflow that gets a
lot of focus because most tooling is focused on the more recommended
approach.

Having said that, I'm sure people would find a feature like you
suggested useful, although I'm not likely to use it myself.  It's
possible that somebody might see your message and implement it, but
usually patches come in from people who feel strongly about a feature
and implement it themselves.  If you feel like you'd like to try such a
change, I'm sure you can find folks to review it and provide feedback.

[0] https://github.com/trast/tbdiff
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: General question about "git range-diff"

[Junio C Hamano]

Robin Dos Anjos <robin_1997@hotmail.fr> writes:

> There are several workarounds to this situation.

It would be much better to avoid getting into a problematic
situation in the first place than having to come up with a
workaround for such a situation.

"git imerge" may be a good tool to know about for that.  You may be
able to avoid having to say: "Gaahh, I am not patient enough to
rebase this series of commits, even though I spent time to carefully
separate into logical and independent steps.  I'll squash them all
into one large blob of changes, even though it means I will lose all
that work."

An "interdiff" that compares the base and the tip of the old and the
new iterations is certainly a way to compare the changes as a whole,
in exchange for loss of the diff between the log messages and other
commit metadata.  Adding such a mode to the "range-diff" command
might not be a bad idea.

RE: General question about "git range-diff"

[Robin Dos Anjos]

Thank you both for your very quick answers and recommendations! I will check your links. That sounds really interesting.
I'm happy to hear that you don't find my suggestion entirely stupid. My use case is so specific that I wasn't sure it would be very relevant as a feature request.

I will probably take a look at the source code too. But to be very honest, my experience with C is quite limited. I have the basics, but I never practiced it in a real world project. So a codebase such as git's will be way more intimidating to me than sending a message to this mailing list. Building git from the sources would be a good start.

It would be an immense honor for me to invest some time to add a feature to git. But adding this mode to "git range-diff" is probably very ambitious and not very beginner-friendly. I will check the code and see how it goes. We never know!

If you have further recommendations to start this journey, I will be very happy to hear them, of course. Thank you again!