From: Sergey Organov <sorganov@gmail.com> To: Johannes Schindelin <Johannes.Schindelin@gmx.de> Cc: phillip.wood@dunelm.org.uk, Igor Djordjevic <igor.d.djordjevic@gmail.com>, Git mailing list <git@vger.kernel.org>, Jacob Keller <jacob.keller@gmail.com>, Johannes Sixt <j6t@kdbg.org>, Junio C Hamano <gitster@pobox.com> Subject: Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear) Date: Wed, 07 Mar 2018 17:34:07 +0300 Message-ID: <87ina8ymxs.fsf@javad.com> (raw) In-Reply-To: <nycvar.QRO.7.76.6.1803070756550.20700@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz> (Johannes Schindelin's message of "Wed, 7 Mar 2018 07:58:43 +0100 (STD)") Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > Hi Sergey, > > On Wed, 7 Mar 2018, Sergey Organov wrote: > >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: >> >> > On Tue, 6 Mar 2018, Phillip Wood wrote: >> > >> >> On 03/03/18 00:29, Igor Djordjevic wrote: >> >> > >> >> > On 02/03/2018 12:31, Phillip Wood wrote: >> >> >> >> >> >>> Thinking about it overnight, I now suspect that original proposal >> >> >>> had a mistake in the final merge step. I think that what you did is >> >> >>> a way to fix it, and I want to try to figure what exactly was wrong >> >> >>> in the original proposal and to find simpler way of doing it right. >> >> >>> >> >> >>> The likely solution is to use original UM as a merge-base for final >> >> >>> 3-way merge of U1' and U2', but I'm not sure yet. Sounds pretty >> >> >>> natural though, as that's exactly UM from which both U1' and U2' >> >> >>> have diverged due to rebasing and other history editing. >> >> >> >> >> >> Hi Sergey, I've been following this discussion from the sidelines, >> >> >> though I haven't had time to study all the posts in this thread in >> >> >> detail. I wonder if it would be helpful to think of rebasing a merge >> >> >> as merging the changes in the parents due to the rebase back into the >> >> >> original merge. So for a merge M with parents A B C that are rebased >> >> >> to A' B' C' the rebased merge M' would be constructed by (ignoring >> >> >> shell quoting issues) >> >> >> >> >> >> git checkout --detach M >> >> >> git merge-recursive A -- M A' >> >> >> tree=$(git write-tree) >> >> >> git merge-recursive B -- $tree B' >> >> >> tree=$(git write-tree) >> >> >> git merge-recursive C -- $tree C' >> >> >> tree=$(git write-tree) >> >> >> M'=$(git log --pretty=%B -1 M | git commit-tree -pA' -pB' -pC') >> >> >> >> >> >> This should pull in all the changes from the parents while preserving >> >> >> any evil conflict resolution in the original merge. It superficially >> >> >> reminds me of incremental merging [1] but it's so long since I looked at >> >> >> that I'm not sure if there are any significant similarities. >> >> >> >> >> >> [1] https://github.com/mhagger/git-imerge >> >> > >> >> > Interesting, from quick test[3], this seems to produce the same >> >> > result as that other test I previously provided[2], where temporary >> >> > commits U1' and U2' are finally merged with original M as a base :) >> >> > >> >> > Just that this looks like even more straight-forward approach...? >> >> > >> >> > The only thing I wonder of here is how would we check if the >> >> > "rebased" merge M' was "clean", or should we stop for user amendment? >> >> > With that other approach Sergey described, we have U1'==U2' to test with. >> >> >> >> I think (though I haven't rigorously proved to myself) that in the >> >> absence of conflicts this scheme has well defined semantics (the merges >> >> can be commuted), so the result should be predicable from the users >> >> point of view so maybe it could just offer an option to stop. >> > >> > I am not so sure that the result is independent of the order of the >> > merges. In other words, I am not necessarily certain that it is impossible >> > to concoct A,A',B,B' commits where merging B'/B before A'/A has a >> > different result than merging A'/A before B'/B. >> > >> > Remember, when constructing counter-examples to hypotheses, those >> > counter-examples do not really *have* to make sense on their own. For >> > example, A' could introduce *completely different* changes from A, and the >> > same is true for B' and B. >> > >> > I could imagine, for example, that using a ton of consecutive empty lines, >> > and using patches that insert something into these empty lines (and are >> > thusly inherently ambiguous when said set of empty lines has changed), >> > could even introduce a merge conflict in one order, but no conflict in the >> > other. >> > >> > Even so, I think that merging in the order of the parents makes the most >> > sense, and that using that strategy makes sense, too, because you really >> > have to try hard to make it fail. >> >> Alternatively, consider to adopt the original approach that has none of >> these issues as it uses exactly the same method for rebasing merge >> commits that you are already using for rebasing simple commits, not to >> mention the advantage of the built-in consistency check. > > Surely I misunderstand? > > How can your approach -- which relies *very much* on having the original > parent commits -- not *require* that consistency check? I don't understand what you mean, sorry. Could you please point me to the *require* you talk about in the original proposal? > What would your approach (that still has no satisfyingly trivial > explanation, in my mind) Here is one-liner: rebase sides of the merge commit and then 3-way merge them, using original merge commit as merge base. > do if somebody edited a `merge` command and let it merge a completely > unrelated commit? Don't see a problem, sorry. The method should still work, provided you have original merge commit and two new parents for the new merge. You rebase sides of original merge to the new parents, then 3-way merge the results using original merge as base. Once again, if you can rebase simple commit, the method allows to rebase the merge either. -- Sergey
next prev parent reply other threads:[~2018-03-07 14:34 UTC|newest] Thread overview: 173+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-02-16 13:08 Sergey Organov 2018-02-18 4:16 ` Jacob Keller 2018-02-19 5:28 ` Sergey Organov 2018-02-19 23:44 ` Igor Djordjevic 2018-02-20 12:42 ` Sergey Organov 2018-02-27 0:07 ` Johannes Schindelin 2018-02-27 5:01 ` Sergey Organov 2018-02-27 5:30 ` Jacob Keller 2018-02-27 16:21 ` Johannes Schindelin 2018-02-27 18:55 ` Igor Djordjevic 2018-02-27 19:59 ` Igor Djordjevic 2018-02-27 23:27 ` Johannes Schindelin 2018-02-28 2:12 ` Igor Djordjevic 2018-02-28 4:35 ` Igor Djordjevic 2018-02-28 6:14 ` Sergey Organov 2018-02-28 20:53 ` Igor Djordjevic 2018-02-28 5:44 ` Sergey Organov 2018-02-28 19:42 ` Igor Djordjevic 2018-02-27 23:40 ` Igor Djordjevic 2018-02-28 0:10 ` Junio C Hamano 2018-02-28 2:35 ` Igor Djordjevic 2018-02-28 5:27 ` Sergey Organov 2018-02-28 0:36 ` Jacob Keller 2018-02-28 1:33 ` Igor Djordjevic 2018-02-28 1:43 ` Igor Djordjevic 2018-02-28 5:21 ` Sergey Organov 2018-02-28 19:09 ` Igor Djordjevic 2018-03-01 5:27 ` Sergey Organov 2018-02-28 5:19 ` Sergey Organov 2018-02-28 20:25 ` Igor Djordjevic 2018-02-28 22:17 ` Igor Djordjevic 2018-03-01 5:19 ` Sergey Organov 2018-03-01 5:39 ` Sergey Organov 2018-03-02 1:16 ` Igor Djordjevic 2018-03-02 5:40 ` Sergey Organov 2018-03-02 17:45 ` Igor Djordjevic 2018-03-02 11:17 ` [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear) Phillip Wood 2018-03-02 12:36 ` Phillip Wood 2018-03-02 16:02 ` Jacob Keller 2018-03-02 23:33 ` Igor Djordjevic 2018-03-06 10:36 ` Phillip Wood 2018-03-06 18:12 ` Johannes Schindelin 2018-03-06 19:43 ` Igor Djordjevic 2018-03-07 7:26 ` Johannes Schindelin 2018-03-08 11:20 ` Phillip Wood 2018-03-08 12:16 ` Phillip Wood 2018-03-08 16:05 ` Igor Djordjevic 2018-03-11 12:00 ` Johannes Schindelin 2018-03-11 16:33 ` Igor Djordjevic 2018-03-12 10:37 ` Johannes Schindelin 2018-03-12 12:56 ` Sergey Organov 2018-03-13 0:01 ` Igor Djordjevic 2018-03-26 12:03 ` Johannes Schindelin 2018-03-27 5:08 ` Sergey Organov 2018-03-27 13:35 ` Johannes Schindelin 2018-04-02 6:07 ` Sergey Organov 2018-03-12 23:54 ` Igor Djordjevic 2018-03-13 6:25 ` Sergey Organov 2018-03-08 15:56 ` Igor Djordjevic 2018-03-11 12:08 ` Johannes Schindelin 2018-03-11 17:34 ` Igor Djordjevic 2018-03-12 10:46 ` Johannes Schindelin 2018-03-13 0:16 ` Igor Djordjevic 2018-03-26 13:07 ` Johannes Schindelin 2018-03-27 5:51 ` Sergey Organov 2018-03-27 13:49 ` Johannes Schindelin 2018-03-28 5:57 ` Sergey Organov 2018-03-30 13:41 ` Johannes Schindelin 2018-03-30 16:36 ` Sergey Organov 2018-03-28 5:57 ` Sergey Organov [not found] ` <CA+P7+xoDQ2mzhxeZPFhaY+TaSoKkQm=5AtoduHH06-VggOJ2jg@mail.gmail.com> 2018-03-28 11:29 ` Sergey Organov [not found] ` <CA+P7+xo19mHrWz9Fy-ifgCcVJM2xwzcLj7F2NvFe2LwGbaJiDQ@mail.gmail.com> 2018-03-29 5:53 ` Sergey Organov 2018-03-30 10:38 ` Johannes Schindelin 2018-03-30 12:36 ` Sergey Organov 2018-03-30 13:33 ` Johannes Schindelin 2018-03-30 15:13 ` Sergey Organov 2018-03-28 12:10 ` Sergey Organov 2018-03-08 16:07 ` Jacob Keller 2018-03-11 12:11 ` Johannes Schindelin 2018-03-11 17:46 ` Igor Djordjevic 2018-03-08 15:16 ` Igor Djordjevic 2018-03-08 16:21 ` Igor Djordjevic 2018-03-11 12:22 ` Johannes Schindelin 2018-03-14 14:24 ` Sergey Organov 2018-03-14 23:11 ` Igor Djordjevic 2018-03-15 6:00 ` Sergey Organov 2018-03-15 21:51 ` Igor Djordjevic 2018-03-17 2:08 ` Igor Djordjevic 2018-03-19 5:44 ` Sergey Organov 2018-03-19 21:35 ` Igor Djordjevic 2018-03-20 14:43 ` Sergey Organov 2018-03-26 13:47 ` Johannes Schindelin 2018-03-06 23:24 ` Junio C Hamano 2018-03-07 7:09 ` Johannes Schindelin 2018-03-07 18:20 ` Junio C Hamano 2018-03-08 7:03 ` Johannes Schindelin 2018-03-08 8:11 ` Junio C Hamano 2018-03-09 17:09 ` Johannes Schindelin 2018-03-02 16:00 ` Jacob Keller 2018-03-02 18:14 ` Igor Djordjevic 2018-03-03 17:29 ` Igor Djordjevic 2018-03-05 5:35 ` Sergey Organov 2018-03-02 11:31 ` [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear) Phillip Wood 2018-03-03 0:29 ` Igor Djordjevic 2018-03-05 5:00 ` Sergey Organov 2018-03-06 10:52 ` Phillip Wood 2018-03-06 16:56 ` Junio C Hamano 2018-03-08 7:05 ` Johannes Schindelin 2018-03-08 8:18 ` Junio C Hamano 2018-03-11 11:56 ` Johannes Schindelin 2018-03-13 18:24 ` Junio C Hamano 2018-03-26 13:17 ` Johannes Schindelin 2018-03-05 17:29 ` Johannes Schindelin 2018-03-06 23:21 ` Igor Djordjevic 2018-03-07 7:04 ` Johannes Schindelin 2018-03-06 10:45 ` Phillip Wood 2018-03-06 11:45 ` Sergey Organov 2018-03-08 16:30 ` Igor Djordjevic 2018-03-06 18:12 ` Johannes Schindelin 2018-03-07 5:08 ` Sergey Organov 2018-03-07 6:58 ` Johannes Schindelin 2018-03-07 14:34 ` Sergey Organov [this message] 2018-03-08 6:45 ` Johannes Schindelin 2018-03-12 12:31 ` Sergey Organov 2018-03-26 11:37 ` Johannes Schindelin 2018-03-27 5:11 ` Sergey Organov 2018-03-27 12:55 ` Johannes Schindelin 2018-03-28 4:32 ` Sergey Organov 2018-03-08 11:08 ` Phillip Wood 2018-03-05 17:52 ` Johannes Schindelin 2018-03-13 16:10 ` Sergey Organov 2018-03-14 1:12 ` Igor Djordjevic 2018-03-14 7:21 ` Sergey Organov 2018-03-15 0:09 ` Igor Djordjevic 2018-03-15 7:52 ` Sergey Organov 2018-03-15 23:08 ` Igor Djordjevic 2018-03-16 7:31 ` Sergey Organov 2018-03-17 3:04 ` Igor Djordjevic 2018-03-19 6:01 ` Sergey Organov 2018-03-26 14:11 ` Johannes Schindelin 2018-02-28 0:29 ` Jacob Keller 2018-02-27 11:57 ` Sergey Organov 2018-02-27 18:14 ` Junio C Hamano 2018-02-28 0:30 ` Jacob Keller 2018-02-28 5:54 ` Sergey Organov 2018-02-28 4:53 ` Sergey Organov 2018-03-06 13:26 ` [RFC v2] " Sergey Organov 2018-03-07 6:46 ` Johannes Schindelin 2018-03-07 13:27 ` Sergey Organov 2018-03-07 14:08 ` Johannes Schindelin 2018-03-07 15:16 ` Sergey Organov 2018-03-08 7:01 ` Johannes Schindelin 2018-03-12 12:42 ` Sergey Organov 2018-03-26 11:50 ` Johannes Schindelin 2018-03-08 19:58 ` Igor Djordjevic 2018-03-08 20:27 ` Igor Djordjevic 2018-03-08 22:05 ` Igor Djordjevic 2018-03-08 23:31 ` Igor Djordjevic 2018-03-11 15:47 ` Johannes Schindelin 2018-03-11 20:53 ` Igor Djordjevic 2018-03-12 10:20 ` Johannes Schindelin 2018-03-12 13:49 ` Sergey Organov 2018-03-26 12:44 ` Johannes Schindelin 2018-03-27 5:32 ` Sergey Organov 2018-03-13 0:29 ` Igor Djordjevic 2018-03-26 13:58 ` Johannes Schindelin 2018-03-12 13:07 ` Sergey Organov 2018-03-11 15:40 ` Johannes Schindelin 2018-03-11 22:04 ` Igor Djordjevic 2018-03-12 12:05 ` Sergey Organov 2018-03-26 11:33 ` Johannes Schindelin 2018-03-27 5:34 ` Sergey Organov 2018-03-12 22:41 ` Igor Djordjevic
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87ina8ymxs.fsf@javad.com \ --to=sorganov@gmail.com \ --cc=Johannes.Schindelin@gmx.de \ --cc=git@vger.kernel.org \ --cc=gitster@pobox.com \ --cc=igor.d.djordjevic@gmail.com \ --cc=j6t@kdbg.org \ --cc=jacob.keller@gmail.com \ --cc=phillip.wood@dunelm.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
git@vger.kernel.org list mirror (unofficial, one of many) This inbox may be cloned and mirrored by anyone: git clone --mirror https://public-inbox.org/git git clone --mirror http://ou63pmih66umazou.onion/git git clone --mirror http://czquwvybam4bgbro.onion/git git clone --mirror http://hjrcffqmbrq6wope.onion/git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V1 git git/ https://public-inbox.org/git \ git@vger.kernel.org public-inbox-index git Example config snippet for mirrors. Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.io/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ code repositories for the project(s) associated with this inbox: https://80x24.org/mirrors/git.git AGPL code for this site: git clone https://public-inbox.org/public-inbox.git