{"thread":{"id":"63596","subject":"RFC - rebase--","startedAt":"2025-06-06T21:00:23Z","lastAt":"2025-06-12T00:24:42Z","messageCount":2,"participants":["Edmundo Carmona Antoranz","Nico Williams"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"519876","messageId":"CAOc6etZm_+FPSgdwXszjqy5VBiQXNStEoOJ7-UF+h3AJhiQ_Ng@mail.gmail.com","threadId":"63596","inReplyTo":null,"subject":"RFC - rebase--","fromName":"Edmundo Carmona Antoranz","fromEmail":"eantoranz@gmail.com","sentAt":"2025-06-06T21:00:10Z","receivedAt":"2025-06-06T21:00:23Z","isPatch":false,"sender":{"key":"eantoranz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1491018?v=4"},"body":"Hi, everybody! It's been a while. I hope you are all doing great.\n\nYou remember that I had spent some time trying to come around ways to\nget rebase to take advantage of the original commits that were being\nrebased to tackle conflict resolution... I don't think that anything\nwas implemented back then from my patches but there were interesting\nconversations about the topic. It had been a while since I stopped\nthinking about the subject but in the last few days I felt like giving\nit another bite and see how far I could take it.\n\nSo, I sat down and wrote rebase--, a pygit2-based script (yeah, I\nknow, I am a shameless cheater :-)) that _attempts_ to run rebases and\ntake advantage of previous merge commits to try and avoid asking the\nuser to redo conflicts **if they are easy to deal with**. It is _not_\nmeant to be a replacement of rebase, given that rebase has a lot of\nvery powerful (not to mention useful!!!) options that I do not want to\nreplicate (hence -- instead of ++). I just want to be able to run a\nstraight-forward non-interactive rebase that might include merges.\n\nAt the time, it is able to give me the expected results in some\nscenarios where git gives up... here's a quick example using a linux\nrepo:\n\n$ git rebase --rebase-merges v2.6.39~100 v2.6.39~80 --onto v2.6.39~110\nThis one breaks on bab0dcc717e2.\n\nwith rebase--:\n$ rebase-- v2.6.39~100 v2.6.39~80 --onto v2.6.39~110\nRebasing 189/189\nResulting commit: dc3441f19784813f65979f279133bff1c2c6642d\n\n(it ran in less that 0.4 sec... working tree does not move, no\nreferences are changed, it's all done \"in-memory\" and writing objects\nin the repo db)\n\nNow,I should expect to see the same differences between v2.6.39~110\nand v2.6.39~100 to be present between dc3441f197848 and v2.6.39~80.\n\n$ git diff v2.6.39~110 v2.6.39~100 | md5sum -\naee0292465ed6ba76fd1d283a820568c  -\n$ git diff dc3441f197848 v2.6.39~80 | md5sum -\naee0292465ed6ba76fd1d283a820568c  -\n\nSo, at least it is working with this example where rebase-- could\nsolve the conflicts by taking the appropriate existing object\n(tree/blob) in full that made sense for each scenario.... if it can't\nsolve it, it just reports where it gave up:\n\n$ rebase-- v2.6.39~20 v2.6.39 --onto v2.6.39~100\nRebasing 49/80\nCould not rebase commit b5e6ab589d570ac79cc939517fab05c87a23c262: We\ncould not merge path mm/page_alloc.c\n\n\nOr with --verbose:\n\n$ rebase-- v2.6.39~20 v2.6.39 --onto v2.6.39~100 --verbose\nRebasing 49/80\nFailed to merge commit b5e6ab589d570ac79cc939517fab05c87a23c262\nCurrent path: mm/page_alloc.c\noriginal object: 3f8bce264df66f712e9a44092f871d9f90eafe22\noriginal parent objects: [570d944daeb5d9cd0593c68b57698b2019acfdc9]\nrebased parent objects: [9f8a97b9a350d17ec070d5e741c04f8d9998e7a8]\nCould not rebase commit b5e6ab589d570ac79cc939517fab05c87a23c262: We\ncould not merge path mm/page_alloc.c\n\nSo, if you feel like it, please, give it a test and let me know how it\ngoes of if you have comments or questions.\n\nMy next steps for it:\n- At the moment, it does not try to _merge_ blobs. It deals with them\n_in full_ and takes a full blob if the scenario allows it. If not, a\nmerge would be required to see if any of the conflicts that is popping\nup was already solved in the original commit being rebased...... I\nwill try to turn that paragraph into code.\n- allow moving the working tree and adjust checked out reference\n- fix bugs\n\nThanks for reading.\nHere's the gh repo:\nhttps://github.com/eantoranz/rebase--\n\nBR!\n"},{"id":"520139","messageId":"aEoaEviYFuQQz04m@ubby","threadId":"63596","inReplyTo":"CAOc6etZm_+FPSgdwXszjqy5VBiQXNStEoOJ7-UF+h3AJhiQ_Ng@mail.gmail.com","subject":"Re: RFC - rebase--","fromName":"Nico Williams","fromEmail":"nico@cryptonector.com","sentAt":"2025-06-12T00:06:42Z","receivedAt":"2025-06-12T00:24:42Z","isPatch":false,"sender":{"key":"nico@cryptonector.com","avatar":null},"body":"On Fri, Jun 06, 2025 at 11:00:10PM +0200, Edmundo Carmona Antoranz wrote:\n> So, I sat down and wrote rebase--, a pygit2-based script (yeah, I\n> know, I am a shameless cheater :-)) that _attempts_ to run rebases and\n> take advantage of previous merge commits to try and avoid asking the\n> user to redo conflicts **if they are easy to deal with**. [...]\n\nThat's cool, but I hope not to ever benefit from it because I prefer\nrebase-only workflows -- look ma'! no merges! :)\n\nI use a different approach which is to use something like a bisection to\nfind the first upstream commit where a conflict arises -if any- so I can\nresolve the conflict there where the information about what changed\nupstream is most relevant.  This is the script I use:\n\nhttps://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee6509c3526297\n\nIn the comments you'll find links to several similar tools:\n\nhttps://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee6509c3526297?permalink_comment_id=4659501#gistcomment-4659501\n\ngit-imerge in particular is real pithy about what it does for you:\n\n| Reduce the pain of resolving merge conflicts to its unavoidable\n| minimum, by finding and presenting the smallest possible conflicts:\n| those between the changes introduced by one commit from each branch.\n\nBut yeah, if you have a codebase that merged from upstream and now you\nwant to rebase it, then using the conflict resolutions from the merges\nmakes sense.  It's just I hope dearly to avoid merges, and IMO more\npeople should do that too.\n\nI get that this message risks starting a flame war :( but it's not my\nintent to start a flame war.  And I get that there are cases where you\nhave to merge features from multiple upstreams and cherry-picking gets\ntricky enough that merging becomes the only viable option.  But if you\nhave to track multiple upstreams and you can help it you'll be much\nbetter off cherry-picking than merging, and in all other cases just\nfollow a rebase workflow.\n\nThis sort of problem (rebasing or merging across massively many commits\nupstream) is the sort where rebase workflows shine precisely because\nyour commits are \"always on top\", therefore they are always easily\nidentified as the commits you want to \"move\" to be based on a new\nupstream HEAD.  With merge workflows you simply can't get the\ninformation you need to resolve conflicts, and the best you can do is\n\"see how I did it before\", but with rebase workflows and conflict\nbisection you get to have the most pristine conflicts -- the ones where\nyou have the most local and upstream information available to help you\nresolve the conflict.\n\nNico\n-- \n"}]}