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
