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

From: Igor Djordjevic <igor.d.djordjevic@gmail.com>
Date: Mar 17, 2018, 02:08 UTC
Message-ID: <d50a4099-9b3a-5aa9-c304-160c62330056@gmail.com>
In-Reply-To: <d5e68db4-8006-2c0e-bc21-0b136503edd9@gmail.com>

On 15/03/2018 00:11, Igor Djordjevic wrote:

Show 26 quoted lines

> 
> > > > 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.

The same goes for this part:

> > > > If the user wants to force a new merge, they simply remove that
> > > > -R flag.

This means that using `-R` flag is sensitive to `--no-ff` rebase option, original merge commit _reused_ (fast-forwarded) when possible (unchanged, and `--no-ff` not provided), or original merge commit _rebased_ (when changed, or `--no-ff` provided).

If `-R` flag is removed, then merge commit is always _recreated_, no matter if `--no-ff` option is used or not.

p.s. I`m still a bit opposed to `-R` flag in the first place, as discussed elsewhere[2][3], but that`s unrelated to this fast-forward discussion.

Related to it, though, if `pick` command would be used instead of `merge -R` to signal merge commit _rebasing_, it would fit into existing logic nicely, where `pick` is already sensitive to `--no-ff` option (for rebasing regular commits). Then `merge` alone could be naturally (and only) used for _recreating_ merge commits, as originally intended (and intuitively expected).

Regards, Buga

[1] https://git-scm.com/docs/git-rebase#git-rebase---no-ff [2] https://public-inbox.org/git/77b695d0-7564-80d7-d9e6-70a531e66eda@gmail.com/ [3] https://public-inbox.org/git/a3d40dca-f508-5853-89bc-1f9ab393416b@gmail.com/