On Mon, Nov 23, 2020 at 5:32 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Alex Henrie <alexhenrie24@xxxxxxxxx> writes: > > > On Mon, Nov 23, 2020 at 3:46 PM Felipe Contreras > > <felipe.contreras@xxxxxxxxx> wrote: > >> > >> This patch leaves everything in place to enable this new mode, but it > >> only gets enabled if the user specifically configures it; > >> > >> pull.rebase = ff-only. > > > > Why not use the existing pull.ff=only option instead of adding a new one? > > If you have pull.rebase=false, "git -c pull.ff=only pull" would fail > as desired upon a non-fast-forward. But if you have > pull.rebase=true, does it fail the same way (not a rhetorical > question; I didn't try)? If so, I agree we do not need a new one. No. It attempts the rebase, because whatever is set in pull.ff affects only the merge mode. Also, I don't think there's any way to tell git rebase to fail if it's not fast-forward (not that we should attempt the rebase anyway). > On the other hand, it looks quite funny for that single variable > that controls the way how pull works, whether rebase or merge is > used, is pull.REBASE. Which is precisely why I wanted to rename it to pull.mode. In my option git pull should have three main modes: 1. fast-forward only 2. merge 3. rebase The fast-forward only mode can be considered a merge, or a rebase, doesn't matter. Cheers. -- Felipe Contreras
