Re: [PATCH v2 02/14] pull: improve default warning

From: Chris Torek <chris.torek@gmail.com>
Date: Dec 5, 2020, 09:23 UTC
Message-ID: <CAPx1Gvf2SZdY_huOGieXD0kJaEn38gsaAiXrV==YxL1-x81dPg@mail.gmail.com>
In-Reply-To: <CAMP44s1=aZL7BMKSjzKJ7qYqg-usScwzRUJmaOhsCGvQ4ieYow@mail.gmail.com>

On Fri, Dec 4, 2020 at 5:59 PM Felipe Contreras <felipe.contreras@gmail.com> wrote:

> But in my mind "fast-forward" is not a noun, it's an adjective, so I
> still expect a noun: fast-forward $what. And I don't have any other
> noun to put there but "merge".

It's a "fast-forward operation". :-)

(The operands are branch name and hash ID.)

It's just been nouned, like "a merge" instead of "a merge commit".

> > > Perhaps: a merge, a rebase, or a fast-forward?
> >
> > Sure, that works; in fact, that's much better than my suggestion.  I like it.

I like this one too.

In a perfect world, I'd have had `git pull` be the user facing command that does one of: fetch only, fetch-and-fast-forward, fetch-and-rebase, or fetch-and-merge. (Obviously one can achieve the fetch-only by running `git fetch`, but `git fetch` is a plumbing command.)

In that same perfect world, the default probably would have been fetch only, but fetch-and-fast-forward (or fail if not fast-forward-able) seems like an OK default as well. But we have to deal with the imperfect world we have. This seems like an OK way to do that.