Re: [PATCH v7 1/1] pull: add ff-only option
- From
Felipe Contreras <felipe.contreras@gmail.com>
- Date
- Nov 24, 2020, 03:45 UTC
- Message-ID
- <CAMP44s1QjgOAq6trBmw5Bxt8aXRqVkOStztFOpJr+ooMEG7K0A@mail.gmail.com>
- In-Reply-To
- <CAMMLpeQmJ7TjMKvtjdczyRX+Kebc9DDDyOJthpA6AwxQqy022Q@mail.gmail.com>
On Mon, Nov 23, 2020 at 7:51 PM Alex Henrie <alexhenrie24@gmail.com> wrote:
Show 24 quoted lines
>
> On Mon, Nov 23, 2020 at 5:52 PM Raymond E. Pasco <ray@ameretat.dev> wrote:
> >
> > I feel like the parsimonious change to make is simply defaulting the
> > existing "pull.ff" to "only". I think someone who has set "pull.rebase"
> > expects pull --rebase behavior just as much as someone who passes
> > --rebase on the command line. The issue in question is what someone who
> > has not made any changes to the settings expects to happen with a plain
> > "git pull", and I certainly agree that people who are not power users
> > expect a fast-forward (I try not to force my opinions on workflow or
> > style when onboarding people to Git, but I do always recommend
> > "pull.ff=only" because I know this is a perennial pitfall).
> >
> > The problem is that, as it stands now, this would just leave the user
> > with a cryptic error message ("Not possible to fast-forward, aborting")
> > when they wanted to see remote changes. I think this might warrant an
> > even more expanded message than the short one in this patch, but I'm
> > not sure exactly what it should say - there are a few things the user
> > might expect, but an error message isn't the best place for a crash
> > course.
>
> Another problem is that when pull.ff=only but you really do want to
> allow merging if fast-forwarding is impossible, having to type `git
> pull --ff` to get that behavior is *very* counterintuitive :-(Indeed.
It would be much more intuitive to type "git pull --merge" which would override some default (e.g. do not merge unless it's a fast-forward).
-- Felipe Contreras