RE: [PATCH 1/2] doc: pull: explain what is a fast-forward

From: Ævar Arnfjörð Bjarmason <redacted>
Sent: 25 June 2021 11:59

quoted

quoted

So I think it Philip's suggestion makes sense. We're not talking
about how to fast-forward a tape, but what happens in git when we use
that term.

No. In this particular sentence we are using fast-forward *precisely*
in the same way as a tape. We haven't even talked about what
constitutes a "fast-forward" in git jargon.

Substitute the word "fast-forward", and the meaning remains intact:

  After the remote changes have been synchronized, the local `master`
  will be advanced to the same commit as the remote one, therefore
  creating a linear history.

As I already explained.

I think even if you can accurately substitute the jargon it's worth quoting the
jargon, to call out that it's jargon we're using quoted that place and others.

Anyway, that doesn't have much to do with your isolated change, just a
general comment on quoting v.s. not quoting invented v.s. borrowed/reused
words.

quoted

quoted

As an aside after however many years of using git this is the first
time I made the connection to that usage of the term, I thought it
was jargon git invented. That's also something to consider,

I was in your camp, but after thinking deeply about what would be a
better term than "fast-forward" (advance, forward, boost), I realized
that in fact "fast-forward" is perfectly fine because it already
exists in English and conveys precisely the meaning we want: quickly
advance to a desired position.

I think whatever term we're introducing will need git-specific explanation.
E.g. because a "tree" is an everyday object our use of it needs explaining.

quoted

quoted

I've also actually seen an interacted with a tape record and VHS tape
in my lifetime, but I suspect many readers of this documentation have

not.

quoted

But they have pressed fast-forward on their Roku control, or whatever.

Not only is it part of modern technology, but it's even used inside
films, TV shows, and video games. See TV Tropes for dozens of examples
where inside the film they fast-forward [1].

Unfortunately I haven't been able to non-fast-forward say the Game of
Thrones TV show in such a way that the latest seasons makes any sense,
since no amount of button mashing will merge their version with mine :)

So I think in the context of us using this jargon to describe git-specific
concepts the connection to reality is tenuous at best

quoted

This is one of those rare occasions where I think the git project
chose the perfect word.

I agree.

Perhaps, it's not like I've got much in the way of a holistic world view with
which to replace it.

I do think "perfect" would do a few things it doesn't though, imagine reading
about it for the first time and not making the connection to tapes. Is it an
optimization? Is there a slow-forward? What if upstream rewound there
branch and I merge, is that a merge-backwards?

It's not immediately obvious how rebase/merge/fast-forward relate or
if/when (e.g. merge sometimes being a merge-ff) they're incompatible
concepts.

On the one hand, I think fast-forward is an entirely suitable term for git to use, based on what it does.  Instantaneously moving the branch head pointer forward to the new head
On the other hand I think it is distinctly different from the use with transport controls for linear media (ie tape - video or audio).
For all of them fast-forward moves the play/record point relative to the media, maybe to the end (or to "now"), maybe not.  There may or may not be a cueing play that happens while the tape is moving.
For a modern stream (eg podcast) player, such as BBC Sounds (via its web-site) there is no fast-forward control.  There is play/pause, +20 and -20 seconds, go to the start of the stream and (for live broadcasts) go to now.  The latter is very close to Git's fast-forward, but is not labelled as such.  There is also a time-line, where the user can go to an arbitrary point in time and play from there.
Hardware players do have fast-forward controls, even for streams, or files.

So, yes, the term is very widely known in the wider world (even for those who didn't grow up with tape).
And yes, irrespective of the above, it makes complete sense for git's usage.

Regards,
Richard.