Re: [PATCH RFC] rebase: respect --ff-only option

[Felipe Contreras <felipe.contreras@gmail.com>]

Phillip Wood wrote:
> On 05/07/2021 10:58, Junio C Hamano wrote:

> My main concern with the new rebase option was about a user invoking 
> 'git rebase -i --ff-only' directly.
> 
> If a user has pull.rebase=interactive and runs 'git pull --ff-only' then 
> I'm not clear what they expect to happen. Assuming we can fast-forward 
> would they expect pull to run 'rebase -i' which would open their editor 
> with the todo list or would they expect that '--ff-only' means "I just 
> want to fast-forward, I don't want to run 'rebase -i'". If it is the 
> latter then we can just invoke 'git merge --ff-only' (so long as we 
> don't mind running the post-merge hook in this case) and not worry about 
> adding more complexity to 'git rebase'

Once again my suggestion is to keep these as orthogonal, then everything
becomes clear:

  git -c pull.mode=ff-only -c pull.rebase=interactive pull

This is just a fast-forward merge (git merge --ff-only).

  git -c pull.mode=ff-only -c pull.rebase=interactive pull --rebase

This is an interactive rebase (--ff-only is ignored).

  git -c pull.mode=ff-only -c pull.rebase=interactive pull --merge

This is a real merge (both --ff-only and --rebase=interactive are ignored).

  git -c pull.mode=ff-only -c pull.rebase=interactive pull --merge --ff-only

This is a --ff-only merge.

> The relevant section of the pull man page only talks about merging in 
> relation to --ff-only

And my suggestion is that it should stay that way.

> > or post-merge
> > operations would want to be carried out even when the history would
> > fast-forward, and making "pull" to perform the fast-forwarding and
> > know which hooks should be called with what parameter so that we
> > could pretend as if the "merge" or "rebase" backend was indeed ran,
> > breaks the abstraction.
> > 
> > So, even though I wish that the world was simpler and we could
> > handle "ff logic" inside "pull", I am not sure if it is a realistic
> > wish.
> 
> I think if we decide that 'pull --ff-only' always implies merging then 
> the world stays fairly simple.

Indeed, which is my suggestion.

> On the other hand if we want to somehow 
> combine rebasing with --ff-only it will be more complicated. If we go 
> for the latter then unless someone comes up with a good use for 'rebase 
> --ff-only' in another context I would prefer the new rebase option to be 
> marked with PARSE_OPT_HIDDEN and that we also avoid making incidental 
> changes the existing rebase options.

Once again, we cannot do that, because then this will be broken:

  git -c pull.ff=only pull --rebase

-- 
Felipe Contreras