On Sat, Dec 5, 2020 at 3:23 AM Chris Torek <chris.torek@xxxxxxxxx> wrote: > > On Fri, Dec 4, 2020 at 5:59 PM Felipe Contreras > <felipe.contreras@xxxxxxxxx> 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". :-) 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. > > > > 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
