Hi Johannes, Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi Buga, > > On Tue, 20 Feb 2018, Igor Djordjevic wrote: > >> I`m really interested in this topic, which seems to (try to) address the >> only "bad feeling" I had with rebasing merges - being afraid of silently >> losing amendments by actually trying to "replay" the merge (where >> additional and possibly important context is missing), instead of really >> "rebasing" it (somehow). > > If those amendments are what you are worried about, why not address them > specifically? > > In other words, rather than performing the equivalent of > > git show <merge>^! | git apply > > (which would of course completely ignore if the rewritten <merge>^2 > dropped a patch, amended a patch, or even added a new patch),
You've already bit this poor thingy to death. Please rather try your teeth on the proposed Trivial Merge (TM) method. Sorry, you will need to actually read the proposal should you decide to. > what you really want is to figure out what changes the user made when > merging, Exactly! It's all and only about changes, I'm glad you are starting to get it. > and what merge strategy was used to begin with. No. It's in Git core philosophy to store only result, independent on the way the result has been achieved. Only result matters. I could have got merge result out of thin air, and Git won't care, and will store it for me safely. The proposed (TM) method will ensure it's still stored safely after rebasing. > To see what I mean, look at the output of `git show 0fd90daba8`: it shows > how conflicts were resolved. By necessity, this is more complicated than a > simple diff: it is *not* as simple as taking a diff between two revisions > and applying that diff to a third revision. There were (at least) three > revisions involved in the original merge commit, and recreating that merge > commit faithfully means to represent the essence of the merge commit > faithfully enough to be able to replay it on a new set of at least three > revisions. Even better: we have at least 3 source revisions and 2 new revisions to base 3-rd new revision upon. Proposed (TM) method will use all of them. > That can be simplified to two-way diffs only in very, very special > circumstances, and in all other cases this simplification will simply > fall on its nose. No, Done Right (TM) it won't fall as N-way-diff is nothing more than N-1 simple diffs, trivially combined. > If the proposed solution was to extend `git apply` to process combined > diffs, I would agree that we're on to something. That is not the proposed > solution, though. I'm glad you finally got the point. Proposed (TM) method effectively 'git apply' combined diffs, yes. I just defined it in terms of commits rather than diffs, as it's simpler to understand and to reason about it that way. > > In short: while I am sympathetic to the desire to keep things simple, Proposed (TM) method is complex enough to solve the problem at hand. No need to ask for more complexity. > the idea to somehow side-step replaying the original merge seems to be > *prone* to be flawed. Exactly! That's why current approach to rebase merges is flawed, and that's why proposed (TM) method does reply entire original merges. -- Sergey
