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

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

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

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