On Sat, Dec 5, 2020 at 3:23 AM Chris Torek [off-list ref] wrote:

On Fri, Dec 4, 2020 at 5:59 PM Felipe Contreras
[off-list ref] wrote:

quoted

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". :-)

A fast-forward operation that does what?

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

Except there's a difference between telling git: "do a fast-forward
merge", and "do a fast-forward merge commit". The latter doesn't
really make sense.

quoted

quoted

quoted

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.

In the slightly more perfect word I'm aiming for those two modes could
be achieved with the pull.mode configuration:

* "pull.mode=none" would be the same as "fetch only"
* "pull.mode=ff-only" would be the same as "fetch-and-fast-forward"

But first this configuration has to actually be introduced. It didn't
happen in 2014, maybe it will happen this time. Who knows.

Cheers.

-- 
Felipe Contreras