From: Phillip Wood <phillip.wood@talktalk.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Igor Djordjevic <igor.d.djordjevic@gmail.com>
Cc: Phillip Wood <phillip.wood@dunelm.org.uk>,
Jacob Keller <jacob.keller@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(RoadClear)
Date: Thu, 8 Mar 2018 12:16:41 +0000 [thread overview]
Message-ID: <483674f8-4097-a374-c8f3-cf56cbb92042@talktalk.net> (raw)
In-Reply-To: <c5a5c2cc-6a11-440f-5b9b-964ae1ca07dd@talktalk.net>
On 08/03/18 11:20, Phillip Wood wrote:
> On 07/03/18 07:26, Johannes Schindelin wrote:
>> Hi Buga,
>>
>> On Tue, 6 Mar 2018, Igor Djordjevic wrote:
>>
>>> On 06/03/2018 19:12, Johannes Schindelin wrote:
>>>>
>>>>>> And I guess being consistent is pretty important, too - if you add new
>>>>>> content during merge rebase, it should always show up in the merge,
>>>>>> period.
>>>>>
>>>>> Yes, that should make it easy for the user to know what to expect from
>>>>> rebase.
>>>>
>>>> [...]
>>>>
>>>> It will be slightly inconsistent. But in a defendable way, I think.
>>>
>>> I like where this discussion is heading, and here`s what I thought
>>> about it :)
>>>
>>> [...]
>>>
>>> Here`s a twist - not letting `merge` trying to be too smart by
>>> figuring out whether passed arguments correspond to rewritten
>>> versions of the original merge parents (which would be too
>>> restrictive, too, I`m afraid), but just be explicit about it, instead!
>>
>> That's the missing piece, I think.
>>
>>> So, it could be something like:
>>>
>>> merge -C deadbee 123abc:cafecafe 234bcd:bedbedbed
>>
>> I like where this is heading, too, but I do not think that we can do this
>> on a per-MERGE_HEAD basis. The vast majority of merge commits, in
>> practice, have two parents. So the `merge` command would actually only
>> have one revision to merge (because HEAD is the implicit first parent). So
>> that is easy.
>>
>> But as soon as you go octopus, you can either perform an octopus merge, or
>> rebase the original merge commit. You cannot really mix and match here.
>>
>> Unless we reimplement the octopus merge (which works quite a bit
>> differently from the "rebase merge commit" strategy, even if it is
>> incremental, too), which has its own challenges: if there are merge
>> conflicts before merging the last MERGE_HEAD, the octopus merge will exit
>> with status 2, telling you "Should not be doing an octopus.". While we
>> will want to keep merge conflict markers and continue with the "rebase the
>> original merge commit" strategy.
>>
>> And it would slam the door shut for adding support for *other* merge
>> strategies to perform a more-than-two-parents merge.
>>
>> Also, I do not think that it makes a whole lot of sense in practice to let
>> users edit what will be used for "original parent". If the user wants to
>> do complicated stuff, they can already do that, via `exec`. The `merge`
>> command really should be about facilitating common workflows, guiding the
>> user to what is sane.
>>
>> Currently my favorite idea is to introduce a new flag: -R (for "rebase the
>> original merge commit"). It would look like this:
>>
>> merge -R -C <original-merge> <merge-head> # <oneline>
>>
>> This flag would of course trigger the consistency check (does the number
>> of parents of the original merge commit agree with the parameter list? Was
>> an original merge commit specified to begin with?), and it would not fall
>> back to the recursive merge, but error out if that check failed.
>>
>> Side note: I wonder whether we really need to perform the additional check
>> that ensures that the <merge-head> refers to the rewritten version of the
>> original merge commit's parent.
>>
>> Second side note: if we can fast-forward, currently we prefer that, and I
>> think we should keep that behavior with -R, too.
>
> I think that would be a good idea to avoid unpleasant surprises.
Oops that was referring to the first side note. I think fast forwarding
is a good idea. I'm not so sure about checking that <merge-head> refers
to the rewritten version of the original merge commit's parent any more
though. Having thought some more, I think we would want to allow the
user to rearrange a topic branch that is the parent of a merge and that
would require allowing a different parent as the old parent could be
dropped or swapped with another commit in the branch. I can't think of a
way to mechanically check that the new parent is 'somehow derived from'
the old one.
>> If the user wants to force a new merge, they simply remove that -R flag.
>>
>> What do you think?
>
> I did wonder about using 'pick <original-merge>' for rebasing merges and
> keeping 'merge ...' for recreating them but I'm not sure if that is a
> good idea. It has the advantage that the user cannot specify the wrong
> parents for the merge to be rebased as 'git rebase' would work out if
> the parents have been rebased, but maybe it's a bit magical to use pick
> for merge commits. Also there isn't such a simple way for the user to go
> from 'rabase this merge' to 'recreate this merge' as they'd have to
> write the whole merge line themselves (though I guess something like
> emacs' git-rebase.el would be able to help with that)
Scrub that, it is too magical and I don't think it would work with
rearranged commits - it's making the --preserve-merges mistake all over
again. It's a shame to have 'merge' mean 'recreate the merge' and
'rebase the merge' but I don't think there is an easy way round that.
> Best Wishes
>
> Phillip
>
>
>> Ciao,
>> Dscho
>>
>
next prev parent reply other threads:[~2018-03-08 12:16 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 [this message]
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=483674f8-4097-a374-c8f3-cf56cbb92042@talktalk.net \
--to=phillip.wood@talktalk.net \
--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).