Martin von Zweigbergk <martinvonz@xxxxxxxxx> writes: > On Tue, Apr 19, 2022 at 5:25 AM Sergey Organov <sorganov@xxxxxxxxx> wrote: >> [...] >> so I'd still propose to >> *rebase* merge *commits* as *content*, without any additional info being >> used, if at all possible. > > Rebasing is about applying changes from some commit onto some other > commit, as I'm sure you know. Yep. > What Elijah and I are proposing is to > consider the changes in the commit to be relative to the auto-merged > parents (regardless of the number of parents - auto-merging a single > parent commit just yields that commit), although I don't think Elijah > phrased it that way. I admit I didn't put enough thought into this new (to me) idea, but I can't immediately see advantages of this method. Suppose, for the sake of the argument, that the merge commit in question has been created without any use of an auto-merge (whatever it actually means) in the first place. What's then the reason to consider it to be a diff with respect to an auto-merge? What advantages would it bring? Then, do we need to be able to reproduce that exact auto-merge in 2 years from now for the method to work reliably? If so, isn't it a problem, as we seem to agree that merge algorithms are subject to change over time? Essentially, this method apparently still puts a result of particular procedure at the root of the method, again mixing merge-a-process with merge-commit-the-result, that to me looks fundamentally flawed. I still think that at its core Git should remain indifferent to the way a commit has been created, be it merge or non-merge. OTOH, the method of rebasing merge commits I've described long ago has no assumptions about procedures involved in creation of the commit to be rebased, nor does it need any notion of conflicts being involved in the process, if any. It simply doesn't care, exactly the same way current rebase doesn't care, when it rebases non-merge commits, if they were created, say, using conflicting cherry-picks. What it cares about is preserving the content by properly applying the recorded changes to the new base. This property of the method I've suggested makes me believe it is the best candidate for the core functionality, on top of which other usable features could evolve. Anyway, the choice is up to whoever gets time and desire to implement it, and, not being that guy for now, I'm only looking forward for any suitable solution for reliable rebasing of merge commits. Thanks, -- Sergey Organov
