Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Igor Djordjevic [off-list ref] writes:

Hi Sergey,

On 19/03/2018 06:44, Sergey Organov wrote:

quoted

quoted

quoted

quoted

quoted

quoted

Second side note: if we can fast-forward, currently we prefer
that, and I think we should keep that behavior with -R, too.

I agree.

I'm admittedly somewhat lost in the discussion, but are you
talking fast-forward on _rebasing_ existing merge? Where would it
go in any of the suggested algorithms of rebasing and why?

I readily see how it can break merges. E.g., any "git merge
--ff-only --no-ff" merge will magically disappear. So, even if
somehow supported, fast-forward should not be performed by default
during _rebasing_ of a merge.

Hmm, now that you brought this up, I can only agree, of course.

What I had in my mind was more similar to "no-rebase-cousins", like 
if we can get away without actually rebasing the merge but still 
using the original one, do it. But I guess that`s not what Johannes 
originally asked about.

This is another definitive difference between rebasing (`pick`?) and 
recreating (`merge`) a merge commit - in the case where we`re rebasing, 
of course it doesn`t make sense to drop commit this time (due to 
fast-forward). This does make sense in recreating the merge (only).

Eh, I might take this back. I think my original interpretation (and 
agreement) to fast-forwarding is correct.

But the confusion here comes from `--no-ff` as used for merging, as 
opposed to `--no-ff` as used for rebasing. I _think_ Johannes meant 
the latter one.

In rebasing, `--no-ff` means that even if a commit inside todo list 
isn`t to be changed, do not reuse it but create a new one. Here`s 
excerpt from the docs[1]:

  --no-ff
    With --interactive, cherry-pick all rebased commits instead of 
    fast-forwarding over the unchanged ones. This ensures that the 
    entire history of the rebased branch is composed of new commits.

    Without --interactive, this is a synonym for --force-rebase.


So fast-forwarding in case of rebasing (merge commits as well) is 
something you would want by default, as it wouldn`t drop/lose 
anything, but merely reuse existing commit (if unchanged), instead of 
cherry-picking (rebasing) it into a new (merge) commit anyway.

This sounds like breakage. E.g., it seems to be breaking every "-x ours"
merge out there.

Either you are not understanding how rebase fast-forward works, or 
I`m missing what you are pointing to... Mind explaining how can 
something that`s left unchanged suddenly become a breakage?

It was misunderstanding on my side indeed, sorry.

quoted

Fast-forwarding existing merge, one way or another, still seems to be
wrong idea to me, as merge commit is not only about content change, but
also about joint point at particular place in the DAG.

Not sure what this has to do with rebase fast-forwarding, either - 
nothing changes for fast-forwarded (merge or non-merge) commit in 
question, both content, joint point and everything else stays exactly 
the same. If anything changed, then it can`t/won`t be fast-forwarded, 
being unchanged is a prerequisite.

Let me elaborate a bit. Here`s a starting diagram:

[... detailed explanation skipped for brevity ...]

Does this settle your concerns, or I`m missing something?

Yes, it does, thank you! Leaving as many leading commits as possible
unchanged during rebase is what fast-forward mean in this case then, and
it's pretty OK with me.

quoted

As for fast-forwarding re-merge, explicitly requested, I'm not sure. On
one hand, it's inline with the default "git merge" behavior, on the
other hand, it still feels wrong, somehow.

Regarding fast-forwarding in context of merging, in case where we are 
recreating merges (not rebasing them), following existing `git merge` 
logic might make sense, where I would expect rebasing todo list `merge` 
command to pick-up tricks from `git merge` as needed, like learning 
to accept `--no-ff` option, for example, thus not fast-forwarding 
merges (on request) even when possible.

Though, I do agree that in case you want to recreate an existing merge 
(instead of just rebasing it), `merge` command fast-forwarding might 
probably not be what you want for the most of the time, but I`m afraid 
having rebase todo list `merge` command default behavior different than 
`git merge` default one (in regards to fast-forwarding) would be 
confusing... or not?

From what I could grasp so far, usually Git commands` default 
behavior is (explained to be) chosen per "most common use case", so 
might be non fast-forwarding would be fine as default for rebase todo 
list `merge` command, even though different than `git merge`
itself...?

As far as I can tell, fast-forward as default for "git merge" has been
chosen to avoid excessive unintended merges in typical workflows, and
therefore this decision is not actually applicable to rebasing, I think.
I'm inclined to disable merges to fast-forward during history rebasing,
at least by default.

As far as I can tell, current "--preserve-merges" does fast-forward and
breaks "git merge --ff-only --no-ff" merges, among other things it
breaks, and that was my primary concern here. Didn't check
what "--recreate-merges" does though.

-- Sergey