Igor Djordjevic <igor.d.djordjevic@xxxxxxxxx> writes: > 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. This sounds like breakage. E.g., it seems to be breaking every "-x ours" merge out there. 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. 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. -- Sergey
