Hi, everybody! It's been a while. I hope you are all doing great. You remember that I had spent some time trying to come around ways to get rebase to take advantage of the original commits that were being rebased to tackle conflict resolution... I don't think that anything was implemented back then from my patches but there were interesting conversations about the topic. It had been a while since I stopped thinking about the subject but in the last few days I felt like giving it another bite and see how far I could take it. So, I sat down and wrote rebase--, a pygit2-based script (yeah, I know, I am a shameless cheater :-)) that _attempts_ to run rebases and take advantage of previous merge commits to try and avoid asking the user to redo conflicts **if they are easy to deal with**. It is _not_ meant to be a replacement of rebase, given that rebase has a lot of very powerful (not to mention useful!!!) options that I do not want to replicate (hence -- instead of ++). I just want to be able to run a straight-forward non-interactive rebase that might include merges. At the time, it is able to give me the expected results in some scenarios where git gives up... here's a quick example using a linux repo: $ git rebase --rebase-merges v2.6.39~100 v2.6.39~80 --onto v2.6.39~110 This one breaks on bab0dcc717e2. with rebase--: $ rebase-- v2.6.39~100 v2.6.39~80 --onto v2.6.39~110 Rebasing 189/189 Resulting commit: dc3441f19784813f65979f279133bff1c2c6642d (it ran in less that 0.4 sec... working tree does not move, no references are changed, it's all done "in-memory" and writing objects in the repo db) Now,I should expect to see the same differences between v2.6.39~110 and v2.6.39~100 to be present between dc3441f197848 and v2.6.39~80. $ git diff v2.6.39~110 v2.6.39~100 | md5sum - aee0292465ed6ba76fd1d283a820568c - $ git diff dc3441f197848 v2.6.39~80 | md5sum - aee0292465ed6ba76fd1d283a820568c - So, at least it is working with this example where rebase-- could solve the conflicts by taking the appropriate existing object (tree/blob) in full that made sense for each scenario.... if it can't solve it, it just reports where it gave up: $ rebase-- v2.6.39~20 v2.6.39 --onto v2.6.39~100 Rebasing 49/80 Could not rebase commit b5e6ab589d570ac79cc939517fab05c87a23c262: We could not merge path mm/page_alloc.c Or with --verbose: $ rebase-- v2.6.39~20 v2.6.39 --onto v2.6.39~100 --verbose Rebasing 49/80 Failed to merge commit b5e6ab589d570ac79cc939517fab05c87a23c262 Current path: mm/page_alloc.c original object: 3f8bce264df66f712e9a44092f871d9f90eafe22 original parent objects: [570d944daeb5d9cd0593c68b57698b2019acfdc9] rebased parent objects: [9f8a97b9a350d17ec070d5e741c04f8d9998e7a8] Could not rebase commit b5e6ab589d570ac79cc939517fab05c87a23c262: We could not merge path mm/page_alloc.c So, if you feel like it, please, give it a test and let me know how it goes of if you have comments or questions. My next steps for it: - At the moment, it does not try to _merge_ blobs. It deals with them _in full_ and takes a full blob if the scenario allows it. If not, a merge would be required to see if any of the conflicts that is popping up was already solved in the original commit being rebased...... I will try to turn that paragraph into code. - allow moving the working tree and adjust checked out reference - fix bugs Thanks for reading. Here's the gh repo: https://github.com/eantoranz/rebase-- BR!
