On 15/03/2018 00:11, Igor Djordjevic wrote:
>
> > > > 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@xxxxxxxxx/
[3] https://public-inbox.org/git/a3d40dca-f508-5853-89bc-1f9ab393416b@xxxxxxxxx/
