From: Jacob Keller <jacob.keller@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Igor Djordjevic <igor.d.djordjevic@gmail.com>,
Sergey Organov <sorganov@gmail.com>,
Git mailing list <git@vger.kernel.org>,
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: Tue, 27 Feb 2018 16:29:01 -0800 [thread overview]
Message-ID: <CA+P7+xrXy1wCJ6D=3h_db93wLTzj9HGF6M6ptLXgEnSMW9KAwg@mail.gmail.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.1802271718090.56@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>
On Tue, Feb 27, 2018 at 8:21 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi Jake,
>
> On Mon, 26 Feb 2018, Jacob Keller wrote:
>
>> On Mon, Feb 26, 2018 at 4:07 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> >
>> > 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), what you
>> > really want is to figure out what changes the user made when merging, and
>> > what merge strategy was used to begin with.
>> >
>> > 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. 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.
>> >
>> > 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.
>> >
>> > In short: while I am sympathetic to the desire to keep things simple,
>> > the idea to somehow side-step replaying the original merge seems to be
>> > *prone* to be flawed. Any system that cannot accommodate
>> > dropped/changed/added commits on either side of a merge is likely to be
>> > too limited to be useful.
>> >
>>
>>
>> The reason Sergey's solution works is because he cherry picks the
>> merge using each parent first, and then merges the result of those. So
>> each branch of the merge gets one, and then you merge the result of
>> those cherry-picks. This preservers amendments and changes properly,
>> and should result in a good solution.
>
> I saw your patch trying to add a minimal example, and I really want to run
> away screaming.
>
> Do you have any way to describe the idea in a simple, 3-5 lines long
> paragraph?
>
> So far, I just know that it is some sort of confusing criss-cross
> cherry-picking and merging and stuff, but nothing in those steps shouts
> out to me what the *idea* is.
>
Sergey's posted explained it more in detail, at
https://public-inbox.org/git/87y3jtqdyg.fsf@javad.com/
I was mostly just attempting to re-create it in a test case to show
that it could work.
> If it would be something like "recreate the old merge, with merge
> conflicts and all, then generate the diff to the actual tree of the merge
> commit, then apply that to the newly-generated merge", I would understand.
>
It's more or less:
Rebase each parent, then cherry-pick -m<N> the original merge to that
parent, then you merge the result of each cherry-pick, then use the
resulting final merged tree to create the merge pointing at the real
parents instead of the cherry-pick merges.
> I would still suspect that -s ours would be a hard nut for that method,
> but I would understand that idea.
>
The goal of the process isn't to know or understand the "-s ours"
strategy, but simply re-create the contents of the original merge
faithfully, while still preserving the changes done when rebasing the
side branches. Thus it should re-create the contents generated by "-s
ours" the first time, but it doesn't need to do or know anything
special about how the content was created.
> Thanks,
> Dscho
next prev parent reply other threads:[~2018-02-28 0:29 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 ` [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
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 [this message]
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='CA+P7+xrXy1wCJ6D=3h_db93wLTzj9HGF6M6ptLXgEnSMW9KAwg@mail.gmail.com' \
--to=jacob.keller@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=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).