{"thread":{"id":"60459","subject":"General question about \"git range-diff\"","startedAt":"2023-11-02T18:56:56Z","lastAt":"2023-11-03T01:25:16Z","messageCount":4,"participants":["Robin Dos Anjos","brian m. carlson","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"484375","messageId":"PR3P195MB087847E68AD2032148EFCA039BA6A@PR3P195MB0878.EURP195.PROD.OUTLOOK.COM","threadId":"60459","inReplyTo":null,"subject":"General question about \"git range-diff\"","fromName":"Robin Dos Anjos","fromEmail":"robin_1997@hotmail.fr","sentAt":"2023-11-02T18:56:39Z","receivedAt":"2023-11-02T18:56:56Z","isPatch":false,"sender":{"key":"robin_1997@hotmail.fr","avatar":null},"body":"Hi git community!\n\nI'm a bit intimidated as this is my first message in the mailing list but I'll give it a go!\nFirst, 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.\n\nGit 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.\n\nBut 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.\n\nThe 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.\n\nThere are several workarounds to this situation.\n\nThe 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.\n\nAnother 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\n\nWhat 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.\n\nThis 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.\n\nThis 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?\n\nI 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!\n\nThank you for reading my lengthy message and I'm looking forward to reading your insights on the matter!\n\nBest regards,\n\nRobin DOS ANJOS"},{"id":"484378","messageId":"ZUQZF-4CW-FbjfAU@tapette.crustytoothpaste.net","threadId":"60459","inReplyTo":"PR3P195MB087847E68AD2032148EFCA039BA6A@PR3P195MB0878.EURP195.PROD.OUTLOOK.COM","subject":"Re: General question about \"git range-diff\"","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2023-11-02T21:48:07Z","receivedAt":"2023-11-02T21:48:14Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2023-11-02 at 18:56:39, Robin Dos Anjos wrote:\n> Hi git community!\n\nHi,\n\n> I'm a bit intimidated as this is my first message in the mailing list but I'll give it a go!\n\nNo reason to be intimidated.  We're very friendly here.\n\n> This is so useful to me that I'm wondering why \"git range-diff\" does\n> not implement this behavior. We could imagine a flag that would make\n> it behave as I described. Is this something that was ever considered?\n> Are there any technical difficulties that I'm completely missing? Do\n> you think this could be helpful to other people?\n\nI'm not the author of range-diff, but I believe it was based on an\nearlier tool named git-tbdiff[0], which had similar behaviour and\nsimilar limitations.  My guess as to why nobody implemented a feature to\nhandle the squashed commits case is that typically the recommended\nworkflow in Git is to write small independent, logical, well-described,\nbisectable commits, and squashing is not recommended because it destroys\nall the work that people have put into making nice commits.\n\nOf course, in many situations, people don't write nice commits like\nthat, and many commits are effectively fixup commits with very short\nmessages (e.g. \"make it work\"), sometimes containing profanity directed\nat the computer, and in those environments, squashing may be a\nlegitimate choice.  However, it isn't typically a workflow that gets a\nlot of focus because most tooling is focused on the more recommended\napproach.\n\nHaving said that, I'm sure people would find a feature like you\nsuggested useful, although I'm not likely to use it myself.  It's\npossible that somebody might see your message and implement it, but\nusually patches come in from people who feel strongly about a feature\nand implement it themselves.  If you feel like you'd like to try such a\nchange, I'm sure you can find folks to review it and provide feedback.\n\n[0] https://github.com/trast/tbdiff\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"484379","messageId":"xmqqbkcblp1y.fsf@gitster.g","threadId":"60459","inReplyTo":"PR3P195MB087847E68AD2032148EFCA039BA6A@PR3P195MB0878.EURP195.PROD.OUTLOOK.COM","subject":"Re: General question about \"git range-diff\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-11-02T23:21:13Z","receivedAt":"2023-11-02T23:21:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Robin Dos Anjos <robin_1997@hotmail.fr> writes:\n\n> There are several workarounds to this situation.\n\nIt would be much better to avoid getting into a problematic\nsituation in the first place than having to come up with a\nworkaround for such a situation.\n\n\"git imerge\" may be a good tool to know about for that.  You may be\nable to avoid having to say: \"Gaahh, I am not patient enough to\nrebase this series of commits, even though I spent time to carefully\nseparate into logical and independent steps.  I'll squash them all\ninto one large blob of changes, even though it means I will lose all\nthat work.\"\n\nAn \"interdiff\" that compares the base and the tip of the old and the\nnew iterations is certainly a way to compare the changes as a whole,\nin exchange for loss of the diff between the log messages and other\ncommit metadata.  Adding such a mode to the \"range-diff\" command\nmight not be a bad idea.\n\n\n\n"},{"id":"484382","messageId":"PR3P195MB0878B1E5B7E63F767F34EA999BA5A@PR3P195MB0878.EURP195.PROD.OUTLOOK.COM","threadId":"60459","inReplyTo":"xmqqbkcblp1y.fsf@gitster.g","subject":"RE: General question about \"git range-diff\"","fromName":"Robin Dos Anjos","fromEmail":"robin_1997@hotmail.fr","sentAt":"2023-11-03T01:25:12Z","receivedAt":"2023-11-03T01:25:16Z","isPatch":false,"sender":{"key":"robin_1997@hotmail.fr","avatar":null},"body":"Thank you both for your very quick answers and recommendations! I will check your links. That sounds really interesting.\nI'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.\n\nI 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.\n\nIt 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!\n\nIf you have further recommendations to start this journey, I will be very happy to hear them, of course. Thank you again!"}]}