Elijah Newren wrote:
> On Mon, Jul 12, 2021 at 10:08 AM Junio C Hamano <gitster@xxxxxxxxx> wrote:
> >
> > Phillip Wood <phillip.wood123@xxxxxxxxx> writes:
> >
> > > Thanks for revising this patch, I like this approach much better. I do
> > > however have some concerns about the interaction of pull.ff with the
> > > rebase config and command line options. I'd naively expect the
> > > following behavior (where rebase can fast-forward if possible)
> > >
> > > pull.ff pull.rebase commandline action
> > > only not false rebase
> > > only not false --no-rebase fast-forward only
> > > * not false --ff-only fast-forward only
> > > only not false --ff merge --ff
> > > only not false --no-ff merge --no-ff
> > > only false fast-forward only
> > > only false --rebase rebase
> > > only false --ff merge --ff
> > > only false --no-ff merge --no-ff
> >
> > Do you mean by "not false" something other than "true"? Are you
> > trying to capture what should happen when these configuration
> > options are unspecified as well (and your "not false" is "either set
> > to true or unspecified")? I ask because the first row does not make
> > any sense to me. It seems to say
> >
> > "If pull.ff is set to 'only', pull.rebase is not set to 'false',
> > and the command line does not say anything, we will rebase".
>
> I think Phillip is trying to answer what to do when pull.ff and
> pull.rebase conflict. If I read his "not false" means "is set to
> something other than false", then I agree with his table, but I think
> he missed covering some cases.
>
> I think his table says that pull.rebase=false cannot conflict with
> pull.ff settings, but any other value for pull.rebase can. That makes
> sense to me.
>
> I'd similarly say that pull.ff=true cannot conflict with any
> pull.rebase settings...but that both pull.ff=only AND pull.ff=false
> conflict with pull.rebase={true,merges}.
>
> My opinion would be:
> * conflicting command line flags results in the last one winning.
> * --no-rebase makes pull.ff determine the action.
> * --ff makes pull.rebase determine the action.
> * any other command line flag (-r|--rebase|--no-ff|--ff-only)
> overrides both pull.ff and pull.rebase
> * If no command line option is given, and pull.ff and pull.rebase
> conflict, then error out.
>
> I believe my recommendation above is consistent with every entry in
> Phillip's table except the first line (where I suggest erroring out
> instead).
No:
git -c pull.ff=only -c pull.rebase=true pull --ff
In Phillip's table that does a merge, in your rules that's a rebase.
Moreover, since when does git do something different depending if the
action was configured or specified in the command line? They are
supposed to be two ways of doing th same thing:
git -c pull.ff=only -c pull.rebase=true pull
git -c pull.ff=only pull --rebase
Why would those do different things?
The documentation is pretty clear:
See `pull.rebase`, `branch.<name>.rebase` and `branch.autoSetupRebase` in
linkgit:git-config[1] if you want to make `git pull` always use
`--rebase` instead of merging.
If you start adding exceptions on top of exceptions the documentation
will become a mess.
--
Felipe Contreras
