Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
> In other words: --rebase should disable the --ff-only mode.
>
> Also, we would want --no-rebase to disable the default --ff-only mode.
Yes, and for that a configured pull.rebase counts the same as a
command line option. As you agreed earlier in the part omitted from
the quote with my "I would have expected...", we want to say:
There are two ways to consolidate your own work with the history
of the other side, that gives a result in vastly different
shapes that suit for different workflows, and "git pull" will
not choose between them for you. Unless you say which one
between rebase and merge you want to use, it will work only for
fast-forward updating from the other side and nothing else.
and the "default to --ff-only when the user does not say" is a means
to do so. When the end-user gives an explicit preference between
the merge/rebase, none of the above would apply.
> That would require changing the semantics of --ff-only, so that "git
> pull --no-rebase --ff-only" doesn't make sense (as --ff-only is
> overridden by --no-rebase).
I do not think such a conclusion follows from "we do not want to use
the 'by default force the --ff-only' when the user chooses between
merge and rebase". Specifically, I do not agree with "as --ff-only
is overridden" in your statement.
When the end user says "git pull --no-rebase --ff-only", it means to
me:
I choose not to use rebase---my preference is to merge in the
other history into mine, and I want to reject any non-fast
update in this invocation.
and I find it quite sensible, especially in a modern world where you
practically must set pull.rebase to one way or the other. A
developer X, an individual contributor to the project who uses
rebase most of the time, may use "git pull --no-rebase" from
somebody else's repository (i.e. not X's "upstream") when a help is
offered by another developer Y who forked from X to advance X's
work. If the upstream project does not want to see merge commits in
a side branch (i.e. the history X offers to the project), X may ask
Y to make sure Y builds on top of the whole of X's work, and adding
"--ff-only" to the command line would be a way to make sure the
result is fast-forward.
> If we do this, then the only time where --ff-only would make sense is
> in "git pull --ff-only" (no --rebase or --no-rebase), and if we change
> the semantics this way, then there's no need for my suggested
> pull.mode (although it still might be desired).
>
> Moreover, I see no tests that check for this new behavior.
A proposal to change behaviour needs to come with tests to protect
new behaviour before we can merge, but we should be more lenient on
a patch with RFC label on it ;-).
Apparently the patch had me say "I am not seeing what problem this
tries to solve, exactly", and a test may have helped to demonstrate
the intention of the change better, even in its RFC state.
