On 08/03/2018 20:58, Igor Djordjevic wrote: > > > Phillip's method is essentially merging the new tips into the original > > merge, pretending that the new tips were not rebased but merged into > > upstream. > > [...] > > Here`s a starting point, two commits A and B, merged into M: > > (3) ---A > \ > M > / > ---B > > > According the "patch theory"[1] (which might not be too popular > around here, but should serve the purpose for what I`m trying to > explain), each merge commit can be "transformed" to two non-merge > commits, one on top of each of the merge parents, where new commit > brings its original merge parent commit tree to the state of the > merge commit tree: > > (4) ---A---U1 > > > > ---B---U2 > > > Now, we have two new commits, U1 and U2, each having the same tree as > previous merge commit M, but representing changes in regards to > specific parents - and this is essentially what Sergey`s original > approach was using (whether he knew it, or not). > > When it comes to rebasing, it`s pretty simple, too. As this: > > (5) ---X1---o---o---o---o---o---X2 (master) > |\ > | A1---A2---A3 > | \ > | M > | / > \-B1---B2---B3 > > ... actually equals this: > > (6) ---X1---o---o---o---o---o---X2 (master) > |\ > | A1---A2---A3---U1 > | > | > | > \-B1---B2---B3---U2 > > ... where trees of M, U1 and U2 are same, and we can use the regular > rebase semantics and rebase it to this: > > (7) ---X1---o---o---o---o---o---X2 (master) > |\ > | A1'--A2'--A3'--U1' > | > | > | > \-B1'--B2'--B3'--U2' > > ... which is essentially this again: > > (8) ---X1---o---o---o---o---o---X2 (master) > |\ > | A1'--A2'--A3' > | \ > | M' > | / > \-B1'--B2'--B3' > Having explained all this, I realized this is the same "essentially merging the new tips into the original pretending that the new tips were not rebased but merged into upstream" as Phillip`s one, just that we have additional temporary commits U1 and U2 (as per mentioned "patch theory") :) Merging U1' and U2' with M as a base can initially be presented like this as well (what Phillip`s approach would yield): git merge-recursive U1 -- M U1' tree="$(git write-tree)" git merge-recursive U2 -- $tree U2' tree="$(git write-tree)" ..., where we know U1 = U2 = M (in regards to trees), so this is the same as: git merge-recursive M -- M U1' tree="$(git write-tree)" git merge-recursive M -- $tree U2' tree="$(git write-tree)" ..., which can be further simplified, being the same as: git merge-recursive M -- U1' U2' tree="$(git write-tree)" ... which is exactly what Sergey`s (updated) approach suggests, merging U1' and U2' with M as merge-base (and shown inside that sample implementation script I provided[1]) :) With all this said, I think it`s safe to say these two approaches are exactly the same, just Sergey`s being simplified (thus harder to initially understand), and the only actual question is whether we value U1' and U2' enough, as possible "something suspicious happened" indicators, to use them, or not. I would think yes, but I would be open for more samples of where do they become useful for reporting "suspicious activity", too. Regards, Buga [1] https://public-inbox.org/git/b11785bd-5c96-43c1-95d8-b28eccfd13c8@xxxxxxxxx/
