From: "Phillip Wood" <phil@philandanna.no-ip.org>
To: Igor Djordjevic <igor.d.djordjevic@gmail.com>,
Sergey Organov <sorganov@gmail.com>
Cc: Git mailing list <git@vger.kernel.org>,
Jacob Keller <jacob.keller@gmail.com>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Johannes Sixt <j6t@kdbg.org>, Junio C Hamano <gitster@pobox.com>
Subject: Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)
Date: Fri, 02 Mar 2018 11:17:21 -0000 [thread overview]
Message-ID: <ed4d2b30-2dea-740b-6283-973c798f619d@philandanna.no-ip.org> (raw)
In-Reply-To: f1a960dc-cc5c-e7b0-10b6-39e5516655b3@gmail.com
On 02/03/18 01:16, Igor Djordjevic wrote:
>
> Hi Sergey,
>
> On 01/03/2018 06:39, Sergey Organov wrote:
>>
>>>> (3) ---X1---o---o---o---o---o---X2
>>>> |\ |\
>>>> | A1---A2---A3---U1 | A1'--A2'--A3'--U1'
>>>> | \ |
>>>> | M |
>>>> | / |
>>>> \-B1---B2---B3---U2 \-B1'--B2'--B3'--U2'
>>>>
>>>
>>> Meh, I hope I`m rushing it now, but for example, if we had decided to
>>> drop commit A2 during an interactive rebase (so losing A2' from
>>> diagram above), wouldn`t U2' still introduce those changes back, once
>>> U1' and U2' are merged, being incorrect/unwanted behavior...? :/
>>>
>>> [...]
>>
>> Yeah, I now see it myself. I'm sorry for being lazy and not inspecting
>> this more carefully in the first place.
>
> No problem, that`s why we`re discussing it, and I`m glad we`re
> aligned now, so we can move forward :)
>
>>> So while your original proposal currently seems like it could be
>>> working nicely for non-interactive rebase (and might be some simpler
>>> interactive ones), now hitting/acknowledging its first real use
>>> limit, my additional quick attempt[1] just tries to aid pretty
>>> interesting case of complicated interactive rebase, too, where we
>>> might be able to do better as well, still using you original proposal
>>> as a base idea :)
>>
>> Yes, thank you for pushing me back to reality! :-) The work and thoughts
>> you are putting into solving the puzzle are greatly appreciated!
>
> You`re welcome, and I am enjoying it :)
>
>> 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.
>
> Yes, this might be it...! ;)
>
> To prove myself it works, I`ve assembled a pretty crazy `-s ours`
> merge interactive rebase scenario, and it seems this passes the test,
> ticking all the check boxes (I could think of) :P
It is interesting to think what it means to faithfully rebase a '-s
ours' merge. In your example the rebase does not introduce any new
changes into branch B that it doesn't introduce to branch A. Had it
added a fixup to branch B1 for example or if the topology was more
complex so that B ended up with some other changes that the rebase did
not introduce into A, then M' would contain those extra changes whereas
'--recreate-merges' with '-s ours' (once it supports it) would not.
>
> Let`s see our starting situation:
>
> (0) ---X8--B2'--X9 (master)
> |\
> | A1---A2---A3 (A)
> | \
> | M (topic)
> | /
> \-B1---B2---B3 (B)
>
>
> Here, merge commit M is done with `-s ours` (obsoleting branch "B"),
> plus amended to make it an "evil merge", where a commit B2 from
> obsoleted branch "B" is cherry picked to "master".
>
> Now, we want to rebase "topic" (M) onto updated "master" (X9), but to
> make things more interesting, we`ll do it interactively, with some
> amendments, drops, additions and even more cherry-picks!
>
> This is what the final result looks like:
>
> (1) ---X8--B2'--X9 (master)
> |\
> | A12--A2'---B3' (A)
> | \
> | M' (topic)
> | /
> \-B1'--B3'---B4 (B)
>
>
> During interactive rebase, on branch "A", we amended A1 into A12,
> dropped A3 and cherry-picked B3. On branch "B", B4 is added, B2' being
> omitted automatically as already present in "master".
>
> So... In comparison to original merge commit M, rebased merge commit
> M' is expected to:
>
> - Add X9, from updated "master"
> - Have A1 changed to A12, due to A12 commit amendment
> - Keep A2, rebased as A2'
> - Remove A3, due to dropped A3 commit
> - Keep amendment from original (evil) merge commit M
> - Miss B1' like M does B, due to original `-s ours` merge strategy
> - Add B2, cherry-picked as B2' into "master"
> - Add B3, cherry-picked as B3' into "A"
> - Add B4, added to "B"
> - Most important, provide safety mechanism to "fail loud", being
> aware of non-trivial things going on, allowing to stop for user
> inspection/decision
>
>
> There, I hope I didn`t miss any expectation. And, it _seems_ to work
> exactly as expected :D
>
> Not to leave this to imagination only, and hopefully helping others
> to get to speed and possibly discuss this, pointing to still possible
> flaws, I`m adding a demo script[1], showing how this exact example
> works.
>
> Note that script _is_ coined to avoid rebase conflicts, as they`re not
> currently important for the point to be made here.
>
> In real life, except for usual possibility for conflicts during
> commit rebasing, we might experience _three_ possible conflict
> situations once "rebased" merge itself is to be created - two when
> rebasing each of temporary merge helper commits, and one on the
> "rebased" merge itself. This is something where we might think about
> user experience, not introducing (too much) confusion...
>
> Regards, Buga
>
> [1] Demonstration script:
> -- >8 --
> #!/bin/sh
>
> # rm -rf ./.git
> # rm -f ./test.txt
>
> git init
>
> touch ./test.txt
> git add -- test.txt
>
> # prepare repository
> for i in {1..8}
> do
> echo X$i >>test.txt
> git commit -am "X$i"
> done
>
> # prepare branch A
> git checkout -b A
> sed -i '2iA1' test.txt
> git commit -am "A1"
> sed -i '4iA2' test.txt
> git commit -am "A2"
> sed -i '6iA3' test.txt
> git commit -am "A3"
>
> # prepare branch B
> git checkout -b B master
> sed -i '5iB1' test.txt
> git commit -am "B1"
> sed -i '7iB2' test.txt
> git commit -am "B2"
> sed -i '9iB3' test.txt
> git commit -am "B3"
>
> git checkout -b topic A
> git merge -s ours --no-commit B # merge A and B with `-s ours`
> sed -i '8iM' test.txt # amend merge commit ("evil merge")
> git commit -am "M"
> git tag original-merge
>
> # master moves on...
> git checkout master
> git cherry-pick B^ # cherry-pick B2 into master
> sed -i "1iX9" test.txt # add X9
> git commit -am "X9"
>
> # (0) ---X8--B2'--X9 (master)
> # |\
> # | A1---A2---A3 (A)
> # | \
> # | M (topic)
> # | /
> # \-B1---B2---B3 (B)
>
> # simple/naive demonstration of proposed merge rebasing logic
> # using described new approach, preserving merge commit manual
> # amendments, testing `-s ours` merge with cherry-picking from
> # obsoleted part, but still respecting interactively rebased
> # added/modified/dropped/cherry-picked commits :)
>
> git checkout A
> git cherry-pick -m1 original-merge # prepare temporary helper commit U1
> git tag U1
> git reset --hard HEAD^^ # drop U1 and A3 from A
> sed -i '/A1/c\A12' test.txt # amend A1 to A12
> git commit -a --amend --no-edit
> git rebase master # rebase A onto master
> git cherry-pick B # cherry-pick B3 into A
> git cherry-pick U1 # "rebase" temporary helper commit U1
> git tag U1-prime
>
> git checkout B
> git cherry-pick -m2 original-merge # prepare temporary helper commit U2
> git tag U2
> git reset --hard HEAD^ # drop U2 from B
> git rebase master # rebase B onto master
> sed -i '12iB4' test.txt # add B4
> git commit -am "B4"
> git cherry-pick U2 # "rebase" temporary helper commit U2
> git tag U2-prime
>
> git branch -f topic A
> git checkout topic
> # merge rebased temporary commits U1' and U2',
> # using original merge commit as a merge base,
> # producing "rebased" merge commit M'
> git read-tree -m --aggressive original-merge A B
> git merge-index -o git-merge-one-file -a
>
> # recognize complex stuff going on during rebasing merge commit,
> # allowing user to inspect result, edit, and continue or abort
> git diff --quiet U1-prime U2-prime
> if test $? -ne 0
> then
> # PLACEHOLDER
> # chance to inspect result, like:
> git diff original-merge
> # edit if needed, continue or abort
> fi
>
> # drop rebased temporary commits U1' and U2'
> git branch -f A A^
> git branch -f B B^
>
> # record branches A and B as parents of "rebased" merge commit M',
> # updating topic branch
> git update-ref refs/heads/topic "$(git show -s --format=%B original-merge | git commit-tree "$(git write-tree)" -p "$(git rev-parse A)" -p "$(git rev-parse B)")"
> git tag angel-merge
>
> # (1) ---X8--B2'--X9 (master)
> # |\
> # | A12--A2'---B3' (A)
> # | \
> # | M' (topic)
> # | /
> # \-B1'--B3'---B4 (B)
>
> # show resulting graph
> # echo
> # git log --all --decorate --oneline --graph
>
> # in comparison to original merge commit M, rebased merge commit
> # M' is expected to:
> #
> # - Add X9, from updated "master"
> # - Have A1 changed to A12, due to A12 commit amendment
> # - Keep A2, rebased as A2'
> # - Remove A3, due to dropped A3 commit
> # - Keep amendment from original (evil) merge commit M
> # - Miss B1' like M does B, due to original `-s ours` merge strategy
> # - Add B2, cherry-picked as B2' into "master"
> # - Add B3, cherry-picked as B3' into "A"
> # - Add B4, added to "B"
> #
> # echo
> # echo 'diff original-merge angel-merge:'
> # git diff original-merge angel-merge
>
next prev parent reply other threads:[~2018-03-02 11:26 UTC|newest]
Thread overview: 173+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-16 13:08 [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear) 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 ` Phillip Wood [this message]
2018-03-02 12:36 ` [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear) 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
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=ed4d2b30-2dea-740b-6283-973c798f619d@philandanna.no-ip.org \
--to=phil@philandanna.no-ip.org \
--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 \
--cc=sorganov@gmail.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).