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

["Kerry, Richard" <richard.kerry@atos.net>]

> From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> Sent: 25 June 2021 11:59

> >> 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.
> 
> >> 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.
> 
> >> 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.
> >
> > 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
 

> > 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.