On Thu, Feb 8, 2018 at 11:13 PM, Johannes Sixt <j...@kdbg.org> wrote: > Am 09.02.2018 um 07:11 schrieb Sergey Organov: >> >> Johannes Schindelin <johannes.schinde...@gmx.de> writes: >>> >>> Let me explain the scenario which comes up plenty of times in my work >>> with >>> Git for Windows. We have a thicket of some 70 branches on top of >>> git.git's >>> latest release. These branches often include fixup! and squash! commits >>> and even more complicated constructs that rebase cannot handle at all at >>> the moment, such as reorder-before! and reorder-after! (for commits that >>> really need to go into a different branch). >> >> >> I sympathize, but a solution that breaks even in simple cases can't be >> used reliably to solve more complex problems, sorry. Being so deep >> into your problems, I think you maybe just aren't seeing forest for the >> trees [1]. > > > Hold your horses! Dscho has a point here. --preserve-merges --first-parent > works only as long as you don't tamper with the side branches. If you make > changes in the side branches during the same rebase operation, this > --first-parent mode would undo that change. (And, yes, its result would be > called an "evil merge", and that scary name _should_ frighten you!) > > -- Hannes
This is the reason I agree with Johannes, in regards to why recreate-merges approach is correct. Yes, an ideal system would be one which correctly, automatically re-creates the merge *as if* a human had re-merged the two newly re-created side branches, and preserves any changes in the result of the merge, such as cases we call "evil merges" which includes necessary changes to resolve conflicts properly. However, I would state that such a system, in order to cause the least surprise to a user must be correct against arbitrary removal, reorder, and addition of new commits on both the main and topic side branches for which we are re-creating the merges. This is problematic, because something like how --preserve-merges --first-parent does not work under this case. As a user of the tool, I may be biased because I already read and understand how recreate-merges is expected to work, but it makes sense to me that the re-creation of the merge merely re-does the merge and any modfications in the original would have to be carried over. I don't know what process we could use to essentially move the changes from the original merge into the new copy. What ever solution we have would need to have a coherent user interface and be presentable in some manner. One way to think about the contents we're wanting to keep, rather than the full tree result of the merge which we had before, what we actually want to keep in some sense is the resulting "diff" as shown by something like the condensed --combined output. This is obviously not really a diff that we can apply. And even if we could apply it, since the merge is occurring, we can't exactly use 3-way merge conflict in order to actually apply the old changes into the new merged setup? Could something like rerere logic work here to track what was done and then re-apply it to the new merge we create? And once we apply it, we need to be able to handle any conflicts that occur because of deleting, adding, or re-ordering commits on the branches we're merging... so in some sense we could have "conflicts of conflicts" which is a scenario that I don't yet have a good handle on how this would be presented to the user. Thanks, Jake
