{"thread":{"id":"62249","subject":"Request for adding a \"one-shot\" rebase strategy where conflicts are only resolved once","startedAt":"2024-10-03T19:06:54Z","lastAt":"2024-10-03T21:30:53Z","messageCount":5,"participants":["Alireza","Kristoffer Haugsbakk","Jeff King","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"504041","messageId":"CAD9n_qgBPDQKF=ZEQ6SWvDCmcUXZvz33zSoHFQSwHmQPWS4z_Q@mail.gmail.com","threadId":"62249","inReplyTo":null,"subject":"Request for adding a \"one-shot\" rebase strategy where conflicts are only resolved once","fromName":"Alireza","fromEmail":"rezaxm@gmail.com","sentAt":"2024-10-03T19:06:28Z","receivedAt":"2024-10-03T19:06:54Z","isPatch":false,"sender":{"key":"rezaxm@gmail.com","avatar":null},"body":"Sometimes a clean merge is possible but with a rebase, in-between\ncommits may raise conflicts in which case a conflict must be resolved\nfor each commit individually, which is not quite productive and at the\nend wouldn't add so much in how the resulting history looks like.\n\nWith a \"one-shot\" rebase, a conflict (if any) is made based on the\nlatest revision, then in-between commits approximated based on that\nresolution. This way the history can be roughly preserved with the\nsame amount of effort while still using a rebase rather than merge.\n"},{"id":"504044","messageId":"f2ae51a2-95e9-43d4-beba-774d05bfc3e9@app.fastmail.com","threadId":"62249","inReplyTo":"CAD9n_qgBPDQKF=ZEQ6SWvDCmcUXZvz33zSoHFQSwHmQPWS4z_Q@mail.gmail.com","subject":"Re: Request for adding a \"one-shot\" rebase strategy where conflicts are only resolved once","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2024-10-03T20:15:21Z","receivedAt":"2024-10-03T20:15:43Z","isPatch":false,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Thu, Oct 3, 2024, at 21:06, Alireza wrote:\n> Sometimes a clean merge is possible but with a rebase, in-between\n> commits may raise conflicts in which case a conflict must be resolved\n> for each commit individually, which is not quite productive and at the\n> end wouldn't add so much in how the resulting history looks like.\n>\n> With a \"one-shot\" rebase, a conflict (if any) is made based on the\n> latest revision, then in-between commits approximated based on that\n> resolution. This way the history can be roughly preserved with the\n> same amount of effort while still using a rebase rather than merge.\n\nHow would this compare to using git-rerere(1)?\n\n-- \nKristoffer Haugsbakk\n"},{"id":"504051","messageId":"CAD9n_qieu_DNqu-X-gTGua+K-vQysYRoDGzEBgwOhH-w4YU1Bg@mail.gmail.com","threadId":"62249","inReplyTo":"f2ae51a2-95e9-43d4-beba-774d05bfc3e9@app.fastmail.com","subject":"Re: Request for adding a \"one-shot\" rebase strategy where conflicts are only resolved once","fromName":"Alireza","fromEmail":"rezaxm@gmail.com","sentAt":"2024-10-03T21:10:12Z","receivedAt":"2024-10-03T21:10:38Z","isPatch":false,"sender":{"key":"rezaxm@gmail.com","avatar":null},"body":"As far as I know, rerere remembera an exact resolution, but with\nrebase you may have to deal with different conflicts for each commit\nThis makes that completely irrelevant, to elaborate there's basically\ntwo possibility:\n(1) a clean merge is possible but individual commits may conflict\n(2) a clean merge is not possible which means there may be conflicts\nat some point onward\n\nThis only creates one conflict off of the latest revision (same as git\nmerge) or skip if a clean merge is possible\nThen each commit is reconstructed based on that resolution so there's\nno back and forth.\n\nHope this helps.\n\nThanks,\n\nOn Thu, Oct 3, 2024 at 11:45 PM Kristoffer Haugsbakk\n<kristofferhaugsbakk@fastmail.com> wrote:\n>\n> On Thu, Oct 3, 2024, at 21:06, Alireza wrote:\n> > Sometimes a clean merge is possible but with a rebase, in-between\n> > commits may raise conflicts in which case a conflict must be resolved\n> > for each commit individually, which is not quite productive and at the\n> > end wouldn't add so much in how the resulting history looks like.\n> >\n> > With a \"one-shot\" rebase, a conflict (if any) is made based on the\n> > latest revision, then in-between commits approximated based on that\n> > resolution. This way the history can be roughly preserved with the\n> > same amount of effort while still using a rebase rather than merge.\n>\n> How would this compare to using git-rerere(1)?\n>\n> --\n> Kristoffer Haugsbakk\n"},{"id":"504055","messageId":"20241003213029.GB12763@coredump.intra.peff.net","threadId":"62249","inReplyTo":"CAD9n_qgBPDQKF=ZEQ6SWvDCmcUXZvz33zSoHFQSwHmQPWS4z_Q@mail.gmail.com","subject":"Re: Request for adding a \"one-shot\" rebase strategy where conflicts are only resolved once","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-10-03T21:30:29Z","receivedAt":"2024-10-03T21:30:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 03, 2024 at 10:36:28PM +0330, Alireza wrote:\n\n> Sometimes a clean merge is possible but with a rebase, in-between\n> commits may raise conflicts in which case a conflict must be resolved\n> for each commit individually, which is not quite productive and at the\n> end wouldn't add so much in how the resulting history looks like.\n> \n> With a \"one-shot\" rebase, a conflict (if any) is made based on the\n> latest revision, then in-between commits approximated based on that\n> resolution. This way the history can be roughly preserved with the\n> same amount of effort while still using a rebase rather than merge.\n\nI'm not quite sure how you'd approximate those fixes in the general\ncase. You could leave the conflict markers in place, making it obvious\nthat the intermediate state is broken, and then replace it all at the\nend.\n\nThat does make me question what the value is in rebasing instead of\nsimply merging, though.\n\nYou might want to peek at git-imerge (which also does rebasing, despite\nthe name):\n\n  https://github.com/mhagger/git-imerge\n\nI think in a sense it is the _opposite_ of what you are asking for, in\nthat it breaks the merge down into its smallest parts by finding the\nconflicting pairs. But I wonder if you'd find the conflicts it produces\nmore pleasant to work with, or more tedious.\n\n-Peff\n"},{"id":"504056","messageId":"Zv8NCxzrYJ6Gi6Yu@tapette.crustytoothpaste.net","threadId":"62249","inReplyTo":"CAD9n_qgBPDQKF=ZEQ6SWvDCmcUXZvz33zSoHFQSwHmQPWS4z_Q@mail.gmail.com","subject":"Re: Request for adding a \"one-shot\" rebase strategy where conflicts are only resolved once","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-03T21:30:51Z","receivedAt":"2024-10-03T21:30:53Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-10-03 at 19:06:28, Alireza wrote:\n> Sometimes a clean merge is possible but with a rebase, in-between\n> commits may raise conflicts in which case a conflict must be resolved\n> for each commit individually, which is not quite productive and at the\n> end wouldn't add so much in how the resulting history looks like.\n> \n> With a \"one-shot\" rebase, a conflict (if any) is made based on the\n> latest revision, then in-between commits approximated based on that\n> resolution. This way the history can be roughly preserved with the\n> same amount of effort while still using a rebase rather than merge.\n\nPeople actually use rebase in some cases because they want conflicts\nthat they won't get with a merge.  For example, for a merge between\n`feature` and `main`, if `main` adds a change A, and `feature` adds a\nchange B that would conflict with A and and removes B, then with a\nmerge, the merge is clean and only A is included.  However, with a\nrebase, there's a conflict, and for some people that is absolutely\ndesired.  We've gotten complaints on the list that merges don't have\nthat behaviour (merges consider only the two heads and the merge base).\n\nI would also point out that your proposed one-shot rebase will make\nreviewing commit by commit much harder since it won't contain the exact\nchanges that the author intended in each commit.  I frequently write\nseries at work and on the Git list that have multiple commits, each of\nwhich is independent and logically bisectable, so that reviewers can\nhave more confidence in my changes and understand them better.  This\nfeature would be confusing to the reviewers, and it might break\nbisectability since the code might not build and pass all the tests at\neach point.\n\nI am also somewhat doubtful that we can come up with a good\napproximation algorithm for resolving conflicts in this way.  I'm\nthinking of some rather tricky conflicts I've had to solve in the past\nand how pretty much any approximation I can imagine would have ended up\nmaking things worse.\n\nPerhaps if you can propose an algorithm for doing this, people can\nprovide you more concrete feedback on your approach and its advantages\nand disadvantages, outside of the more philosophical objections I've\nmentioned above.\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"}]}