Junio C Hamano wrote: > "Elijah Newren via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > --- a/Documentation/config/pull.txt > > +++ b/Documentation/config/pull.txt > > pull.rebase:: > > When true, rebase branches on top of the fetched branch, instead > > of merging the default branch from the default remote when "git > > pull" is run. See "branch.<name>.rebase" for setting this on a > > - per-branch basis. > > + per-branch basis. Incompatible with pull.ff. > > Likewise. > > I think it technically is OK to say "only ff update is allowed" or > "ff update is allowed when able" while saying pull.rebase=yes. > > - For those who say ff=only, the actual value of pull.rebase would > not matter (i.e. the integration immediately finishes by updating > to what was obtained from the upstream because there is no new > development on our own on top of theirs to either replay or > merge). > > - For those who merely allow ff, an update may fast-forward even > when pull.rebase is set to true (or any non-false value), while > we'll replay our own development on top of theirs when their > history is not descendent of ours. > > So I do not see need to declare these combinations "incompatible". > But perhaps I am missing some subtle cases? Doing such a thing would be wrong. As I already explained multiple times, pull.rebase can be overriden by the command line. When doing --merge we want to honor pull.ff, when we don't we want to ignore it. Since both Elijah and Junio have muted me, and they keep making these mistakes, can anybody else forward this point to them? Cheers. -- Felipe Contreras
