patch, 2 partspull: documentation improvements

> We want users to know what is a fast-forward in order to understand the
> default warning.
> 
> Let's expand the explanation in order to cover both the simple, and the
> complex cases with as much detail as possible.
> 
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>   Documentation/git-pull.txt | 41 ++++++++++++++++++++++++++++++++------
>   1 file changed, 35 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
> index 5c3fb67c01..142df1c4a1 100644
> --- a/Documentation/git-pull.txt
> +++ b/Documentation/git-pull.txt
> @@ -41,16 +41,41 @@ Assume the following history exists and the current branch is
>   ------------
>   	  A---B---C master on origin
>   	 /
> -    D---E---F---G master
> +    D---E master
>   	^
>   	origin/master in your repository
>   ------------
>   
>   Then "`git pull`" will fetch and replay the changes from the remote
>   `master` branch since it diverged from the local `master` (i.e., `E`)
> -until its current commit (`C`) on top of `master` and record the
> -result in a new commit along with the names of the two parent commits
> -and a log message from the user describing the changes.
> +until its current commit (`C`) on top of `master`.
> +
> +After the remote changes have been synchronized, the local `master` will
> +be fast-forwarded to the same commit as the remote one, therefore
> +creating a linear history.
> +
> +------------
> +    D---E---A---B---C master, origin/master
> +------------
> +

> On 22/06/21 00.52, Felipe Contreras wrote:
> > We want users to know what is a fast-forward in order to understand the
> > default warning.
> > 
> > Let's expand the explanation in order to cover both the simple, and the
> > complex cases with as much detail as possible.
> > 
> > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> > ---
> >   Documentation/git-pull.txt | 41 ++++++++++++++++++++++++++++++++------
> >   1 file changed, 35 insertions(+), 6 deletions(-)
> > 
> > diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
> > index 5c3fb67c01..142df1c4a1 100644
> > --- a/Documentation/git-pull.txt
> > +++ b/Documentation/git-pull.txt
> > @@ -41,16 +41,41 @@ Assume the following history exists and the current branch is
> >   ------------
> >   	  A---B---C master on origin
> >   	 /
> > -    D---E---F---G master
> > +    D---E master
> >   	^
> >   	origin/master in your repository
> >   ------------
> >   
> >   Then "`git pull`" will fetch and replay the changes from the remote
> >   `master` branch since it diverged from the local `master` (i.e., `E`)
> > -until its current commit (`C`) on top of `master` and record the
> > -result in a new commit along with the names of the two parent commits
> > -and a log message from the user describing the changes.
> > +until its current commit (`C`) on top of `master`.
> > +
> > +After the remote changes have been synchronized, the local `master` will
> > +be fast-forwarded to the same commit as the remote one, therefore
> > +creating a linear history.
> > +
> > +------------
> > +    D---E---A---B---C master, origin/master
> > +------------
> > +
> 
> Isn't fast-forward merge simply moving HEAD to point at newly incoming 
> commit from origin (in this case commit C) without creating merge commit?

> We want users to know what is a fast-forward in order to understand the
> default warning.
>
> Let's expand the explanation in order to cover both the simple, and the
> complex cases with as much detail as possible.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>  Documentation/git-pull.txt | 41 ++++++++++++++++++++++++++++++++------
>  1 file changed, 35 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
> index 5c3fb67c01..142df1c4a1 100644
> --- a/Documentation/git-pull.txt
> +++ b/Documentation/git-pull.txt
> @@ -41,16 +41,41 @@ Assume the following history exists and the current branch is
>  ------------
>  	  A---B---C master on origin
>  	 /
> -    D---E---F---G master
> +    D---E master
>  	^
>  	origin/master in your repository
>  ------------
>  
>  Then "`git pull`" will fetch and replay the changes from the remote
>  `master` branch since it diverged from the local `master` (i.e., `E`)
> -until its current commit (`C`) on top of `master` and record the
> -result in a new commit along with the names of the two parent commits
> -and a log message from the user describing the changes.
> +until its current commit (`C`) on top of `master`.
> +
> +After the remote changes have been synchronized, the local `master` will
> +be fast-forwarded to the same commit as the remote one, therefore

> +creating a linear history.
> +
> +------------
> +    D---E---A---B---C master, origin/master
> +------------
> +
> +However, a non-fast-forward case looks very different:
> +
> +------------
> +	  A---B---C origin/master
> +	 /
> +    D---E---F---G master
> +------------
> +
> +If there are additional changes in the local `master`, it's
> +not possible to fast-forward, so a decision must be made how to
> +synchronize the local, and remote brances.
> +
> +In these situations `git pull` will warn you about your possible
> +options, which are either merge (`--no-rebase`), or rebase (`--rebase`).
> +However, by default it will continue doing a merge.
> +
> +A merge will create a new commit with two parent commits (`G` and `C`)
> +and a log message describing the changes, which you can edit.
>  
>  ------------
>  	  A---B---C origin/master
> @@ -58,8 +83,11 @@ and a log message from the user describing the changes.
>      D---E---F---G---H master
>  ------------
>  
> +Once the merge commit is created (`H`), your local `master` branch has
> +incorporated the changes of the remote `master` branch.
> +
>  See linkgit:git-merge[1] for details, including how conflicts
> -are presented and handled.
> +are presented and handled, and also linkgit:git-rebase[1].
>  
>  In Git 1.7.0 or later, to cancel a conflicting merge, use
>  `git reset --merge`.  *Warning*: In older versions of Git, running 'git pull'
> @@ -248,7 +276,8 @@ version.
>  
>  SEE ALSO
>  --------
> -linkgit:git-fetch[1], linkgit:git-merge[1], linkgit:git-config[1]
> +linkgit:git-fetch[1], linkgit:git-merge[1], linkgit:git-rebase[1],
> +linkgit:git-config[1]
>  
>  GIT
>  ---

> > --- a/Documentation/git-pull.txt
> > +++ b/Documentation/git-pull.txt
> > @@ -41,16 +41,41 @@ Assume the following history exists and the current branch is
> >  ------------
> >  	  A---B---C master on origin
> >  	 /
> > -    D---E---F---G master
> > +    D---E master
> >  	^
> >  	origin/master in your repository
> >  ------------
> >  
> >  Then "`git pull`" will fetch and replay the changes from the remote
> >  `master` branch since it diverged from the local `master` (i.e., `E`)
> > -until its current commit (`C`) on top of `master` and record the
> > -result in a new commit along with the names of the two parent commits
> > -and a log message from the user describing the changes.
> > +until its current commit (`C`) on top of `master`.
> > +
> > +After the remote changes have been synchronized, the local `master` will
> > +be fast-forwarded to the same commit as the remote one, therefore
> 
> Perhaps s/be fast-forwarded/have been 'fast-forward'ed/ ?

> Philip Oakley wrote:
>> On 21/06/2021 18:52, Felipe Contreras wrote:
>>> --- a/Documentation/git-pull.txt
>>> +++ b/Documentation/git-pull.txt
>>> @@ -41,16 +41,41 @@ Assume the following history exists and the current branch is
>>>  ------------
>>>  	  A---B---C master on origin
>>>  	 /
>>> -    D---E---F---G master
>>> +    D---E master
>>>  	^
>>>  	origin/master in your repository
>>>  ------------
>>>  
>>>  Then "`git pull`" will fetch and replay the changes from the remote
>>>  `master` branch since it diverged from the local `master` (i.e., `E`)
>>> -until its current commit (`C`) on top of `master` and record the
>>> -result in a new commit along with the names of the two parent commits
>>> -and a log message from the user describing the changes.
>>> +until its current commit (`C`) on top of `master`.
>>> +
>>> +After the remote changes have been synchronized, the local `master` will
>>> +be fast-forwarded to the same commit as the remote one, therefore
>> Perhaps s/be fast-forwarded/have been 'fast-forward'ed/ ?
> No, there's multiple steps:

>
>  1. origin/master is synchronizd with master on origin
>  2. master is fast-forwarded to origin/master
>
> So, after 1 is done, 2 will happen.
>

> Hi Felipe,
> On 24/06/2021 15:31, Felipe Contreras wrote:
> > Philip Oakley wrote:
> >> On 21/06/2021 18:52, Felipe Contreras wrote:
> >>> --- a/Documentation/git-pull.txt
> >>> +++ b/Documentation/git-pull.txt
> >>> @@ -41,16 +41,41 @@ Assume the following history exists and the current branch is
> >>>  ------------
> >>>  	  A---B---C master on origin
> >>>  	 /
> >>> -    D---E---F---G master
> >>> +    D---E master
> >>>  	^
> >>>  	origin/master in your repository
> >>>  ------------
> >>>  
> >>>  Then "`git pull`" will fetch and replay the changes from the remote
> >>>  `master` branch since it diverged from the local `master` (i.e., `E`)
> >>> -until its current commit (`C`) on top of `master` and record the
> >>> -result in a new commit along with the names of the two parent commits
> >>> -and a log message from the user describing the changes.
> >>> +until its current commit (`C`) on top of `master`.
> >>> +
> >>> +After the remote changes have been synchronized, the local `master` will
> >>> +be fast-forwarded to the same commit as the remote one, therefore
> >> Perhaps s/be fast-forwarded/have been 'fast-forward'ed/ ?
> > No, there's multiple steps:

> Philip Oakley wrote:
>> Hi Felipe,
>> On 24/06/2021 15:31, Felipe Contreras wrote:
>>> Philip Oakley wrote:
>>>> On 21/06/2021 18:52, Felipe Contreras wrote:
>>>>> --- a/Documentation/git-pull.txt
>>>>> +++ b/Documentation/git-pull.txt
>>>>> @@ -41,16 +41,41 @@ Assume the following history exists and the current branch is
>>>>>  ------------
>>>>>  	  A---B---C master on origin
>>>>>  	 /
>>>>> -    D---E---F---G master
>>>>> +    D---E master
>>>>>  	^
>>>>>  	origin/master in your repository
>>>>>  ------------
>>>>>  
>>>>>  Then "`git pull`" will fetch and replay the changes from the remote
>>>>>  `master` branch since it diverged from the local `master` (i.e., `E`)
>>>>> -until its current commit (`C`) on top of `master` and record the
>>>>> -result in a new commit along with the names of the two parent commits
>>>>> -and a log message from the user describing the changes.
>>>>> +until its current commit (`C`) on top of `master`.
>>>>> +
>>>>> +After the remote changes have been synchronized, the local `master` will
>>>>> +be fast-forwarded to the same commit as the remote one, therefore
>>>> Perhaps s/be fast-forwarded/have been 'fast-forward'ed/ ?
>>> No, there's multiple steps:
>> My key point was to 'quote' the fast-forward term.
> fast-forward is an English word [1], there's no need to quote it as if
> it weren't.

>
>> And then (if suitable, with appropriate grammar corrections) indicate
>> subtly that 'nothing actually moved', we just moved the post-it note
>> showing the branch-name on the DAG [hence the confusion about timing] ;-)
> A branch is a "post-it note", moving the post-it note is the same thing
> as moving the branch.
>
> Both the "origin/master" branch, and the "master" branch moved. So I
> don't know how exactly "nothing actually moved".
>
> Perhaps you meant no commit was created, and therefore the DAG didn't
> change.
>
> Maybe instead of saying "creating a linear history", "representing a
> linear history"?
>
> [1] https://www.merriam-webster.com/dictionary/fast-forward
>

> On 24/06/2021 20:05, Felipe Contreras wrote:
> > Philip Oakley wrote:
> >> Hi Felipe,
> >> On 24/06/2021 15:31, Felipe Contreras wrote:
> >>> Philip Oakley wrote:
> >>>> On 21/06/2021 18:52, Felipe Contreras wrote:
> >>>>> --- a/Documentation/git-pull.txt
> >>>>> +++ b/Documentation/git-pull.txt
> >>>>> @@ -41,16 +41,41 @@ Assume the following history exists and the current branch is
> >>>>>  ------------
> >>>>>  	  A---B---C master on origin
> >>>>>  	 /
> >>>>> -    D---E---F---G master
> >>>>> +    D---E master
> >>>>>  	^
> >>>>>  	origin/master in your repository
> >>>>>  ------------
> >>>>>  
> >>>>>  Then "`git pull`" will fetch and replay the changes from the remote
> >>>>>  `master` branch since it diverged from the local `master` (i.e., `E`)
> >>>>> -until its current commit (`C`) on top of `master` and record the
> >>>>> -result in a new commit along with the names of the two parent commits
> >>>>> -and a log message from the user describing the changes.
> >>>>> +until its current commit (`C`) on top of `master`.
> >>>>> +
> >>>>> +After the remote changes have been synchronized, the local `master` will
> >>>>> +be fast-forwarded to the same commit as the remote one, therefore
> >>>> Perhaps s/be fast-forwarded/have been 'fast-forward'ed/ ?
> >>> No, there's multiple steps:
> >> My key point was to 'quote' the fast-forward term.
> > fast-forward is an English word [1], there's no need to quote it as if
> > it weren't.
> 
> You appear to be arguing that your "explain what is a fast-forward"
> (subject line of the patch) doesn't need, within the patch, to explain
> that it is about the term "fast-forward", being used in a Git specific
> way...

> Philip Oakley wrote:
>> On 24/06/2021 20:05, Felipe Contreras wrote:
>> > Philip Oakley wrote:
>> >> Hi Felipe,
>> >> On 24/06/2021 15:31, Felipe Contreras wrote:
>> >>> Philip Oakley wrote:
>> >>>> On 21/06/2021 18:52, Felipe Contreras wrote:
>> >>>>> --- a/Documentation/git-pull.txt
>> >>>>> +++ b/Documentation/git-pull.txt
>> >>>>> @@ -41,16 +41,41 @@ Assume the following history exists and the current branch is
>> >>>>>  ------------
>> >>>>>  	  A---B---C master on origin
>> >>>>>  	 /
>> >>>>> -    D---E---F---G master
>> >>>>> +    D---E master
>> >>>>>  	^
>> >>>>>  	origin/master in your repository
>> >>>>>  ------------
>> >>>>>  
>> >>>>>  Then "`git pull`" will fetch and replay the changes from the remote
>> >>>>>  `master` branch since it diverged from the local `master` (i.e., `E`)
>> >>>>> -until its current commit (`C`) on top of `master` and record the
>> >>>>> -result in a new commit along with the names of the two parent commits
>> >>>>> -and a log message from the user describing the changes.
>> >>>>> +until its current commit (`C`) on top of `master`.
>> >>>>> +
>> >>>>> +After the remote changes have been synchronized, the local `master` will
>> >>>>> +be fast-forwarded to the same commit as the remote one, therefore
>> >>>> Perhaps s/be fast-forwarded/have been 'fast-forward'ed/ ?
>> >>> No, there's multiple steps:
>> >> My key point was to 'quote' the fast-forward term.
>> > fast-forward is an English word [1], there's no need to quote it as if
>> > it weren't.
>> 
>> You appear to be arguing that your "explain what is a fast-forward"
>> (subject line of the patch) doesn't need, within the patch, to explain
>> that it is about the term "fast-forward", being used in a Git specific
>> way...
>
> When you are trying to explain the meaning of a word it's generally
> better to not use that word in the explanation. For example if you are
> trying to explain "recursion", but you use "recursion" in the
> explanation, that kinds of defeats the purpose.
>
> So yes, in the sentence "the local `master` will be fast-forwarded to
> the same commit as the remote one", the verb "fast-forwarded" can easily
> be replaced with "advanced" and no meaning would be lost.
>
> The meaning of this "fast-forward" verb is the same as when you
> fast-forward a tape, and is not git-specific.

> 
> On Thu, Jun 24 2021, Felipe Contreras wrote:
> 
> > Philip Oakley wrote:
> >> On 24/06/2021 20:05, Felipe Contreras wrote:
> >> > Philip Oakley wrote:
> >> >> Hi Felipe,
> >> >> On 24/06/2021 15:31, Felipe Contreras wrote:
> >> >>> Philip Oakley wrote:
> >> >>>> On 21/06/2021 18:52, Felipe Contreras wrote:
> >> >>>>> --- a/Documentation/git-pull.txt
> >> >>>>> +++ b/Documentation/git-pull.txt
> >> >>>>> @@ -41,16 +41,41 @@ Assume the following history exists and the current branch is
> >> >>>>>  ------------
> >> >>>>>  	  A---B---C master on origin
> >> >>>>>  	 /
> >> >>>>> -    D---E---F---G master
> >> >>>>> +    D---E master
> >> >>>>>  	^
> >> >>>>>  	origin/master in your repository
> >> >>>>>  ------------
> >> >>>>>  
> >> >>>>>  Then "`git pull`" will fetch and replay the changes from the remote
> >> >>>>>  `master` branch since it diverged from the local `master` (i.e., `E`)
> >> >>>>> -until its current commit (`C`) on top of `master` and record the
> >> >>>>> -result in a new commit along with the names of the two parent commits
> >> >>>>> -and a log message from the user describing the changes.
> >> >>>>> +until its current commit (`C`) on top of `master`.
> >> >>>>> +
> >> >>>>> +After the remote changes have been synchronized, the local `master` will
> >> >>>>> +be fast-forwarded to the same commit as the remote one, therefore
> >> >>>> Perhaps s/be fast-forwarded/have been 'fast-forward'ed/ ?
> >> >>> No, there's multiple steps:
> >> >> My key point was to 'quote' the fast-forward term.
> >> > fast-forward is an English word [1], there's no need to quote it as if
> >> > it weren't.
> >> 
> >> You appear to be arguing that your "explain what is a fast-forward"
> >> (subject line of the patch) doesn't need, within the patch, to explain
> >> that it is about the term "fast-forward", being used in a Git specific
> >> way...
> >
> > When you are trying to explain the meaning of a word it's generally
> > better to not use that word in the explanation. For example if you are
> > trying to explain "recursion", but you use "recursion" in the
> > explanation, that kinds of defeats the purpose.
> >
> > So yes, in the sentence "the local `master` will be fast-forwarded to
> > the same commit as the remote one", the verb "fast-forwarded" can easily
> > be replaced with "advanced" and no meaning would be lost.
> >
> > The meaning of this "fast-forward" verb is the same as when you
> > fast-forward a tape, and is not git-specific.
> 
> Using quotes for a term like 'fast-forward' or some made up word like
> 'qibbix' doesn't just serve the purpose of clarifying which ones are in
> the dictionary, but also to establish that the quoted word is jargon
> within the context of the documentation.
> 
> If I invent a new and exciting way to cut grass I might say my new
> machine 'shaves' the grass. The word "shave" is something I assume
> everyone knows, but I'm making it clear that I'm referring to the
> exciting mode of operation of my new death machine.
> 
> 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.

> This isn't something for your patch, but I wonder more generally if we
> shouldn't consider moving away from the term entirely, and just say a
> branch was one of:
> 
>     * advanced (or some other such term, forwarded?)
>     * rebased
>     * merged
> 
> The existence (and it being the default) of "merge --ff" makes that
> somewhat difficult, but in those cases we could and probably should just
> also say "advanced" (or whatever), since that's what happened, ditto a
> noop rebase.

> Ævar Arnfjörð Bjarmason wrote:
>> 
>> On Thu, Jun 24 2021, Felipe Contreras wrote:
>> 
>> > Philip Oakley wrote:
>> >> On 24/06/2021 20:05, Felipe Contreras wrote:
>> >> > Philip Oakley wrote:
>> >> >> Hi Felipe,
>> >> >> On 24/06/2021 15:31, Felipe Contreras wrote:
>> >> >>> Philip Oakley wrote:
>> >> >>>> On 21/06/2021 18:52, Felipe Contreras wrote:
>> >> >>>>> --- a/Documentation/git-pull.txt
>> >> >>>>> +++ b/Documentation/git-pull.txt
>> >> >>>>> @@ -41,16 +41,41 @@ Assume the following history exists and the current branch is
>> >> >>>>>  ------------
>> >> >>>>>  	  A---B---C master on origin
>> >> >>>>>  	 /
>> >> >>>>> -    D---E---F---G master
>> >> >>>>> +    D---E master
>> >> >>>>>  	^
>> >> >>>>>  	origin/master in your repository
>> >> >>>>>  ------------
>> >> >>>>>  
>> >> >>>>>  Then "`git pull`" will fetch and replay the changes from the remote
>> >> >>>>>  `master` branch since it diverged from the local `master` (i.e., `E`)
>> >> >>>>> -until its current commit (`C`) on top of `master` and record the
>> >> >>>>> -result in a new commit along with the names of the two parent commits
>> >> >>>>> -and a log message from the user describing the changes.
>> >> >>>>> +until its current commit (`C`) on top of `master`.
>> >> >>>>> +
>> >> >>>>> +After the remote changes have been synchronized, the local `master` will
>> >> >>>>> +be fast-forwarded to the same commit as the remote one, therefore
>> >> >>>> Perhaps s/be fast-forwarded/have been 'fast-forward'ed/ ?
>> >> >>> No, there's multiple steps:
>> >> >> My key point was to 'quote' the fast-forward term.
>> >> > fast-forward is an English word [1], there's no need to quote it as if
>> >> > it weren't.
>> >> 
>> >> You appear to be arguing that your "explain what is a fast-forward"
>> >> (subject line of the patch) doesn't need, within the patch, to explain
>> >> that it is about the term "fast-forward", being used in a Git specific
>> >> way...
>> >
>> > When you are trying to explain the meaning of a word it's generally
>> > better to not use that word in the explanation. For example if you are
>> > trying to explain "recursion", but you use "recursion" in the
>> > explanation, that kinds of defeats the purpose.
>> >
>> > So yes, in the sentence "the local `master` will be fast-forwarded to
>> > the same commit as the remote one", the verb "fast-forwarded" can easily
>> > be replaced with "advanced" and no meaning would be lost.
>> >
>> > The meaning of this "fast-forward" verb is the same as when you
>> > fast-forward a tape, and is not git-specific.
>> 
>> Using quotes for a term like 'fast-forward' or some made up word like
>> 'qibbix' doesn't just serve the purpose of clarifying which ones are in
>> the dictionary, but also to establish that the quoted word is jargon
>> within the context of the documentation.
>> 
>> If I invent a new and exciting way to cut grass I might say my new
>> machine 'shaves' the grass. The word "shave" is something I assume
>> everyone knows, but I'm making it clear that I'm referring to the
>> exciting mode of operation of my new death machine.
>> 
>> 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.

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

>> This isn't something for your patch, but I wonder more generally if we
>> shouldn't consider moving away from the term entirely, and just say a
>> branch was one of:
>> 
>>     * advanced (or some other such term, forwarded?)
>>     * rebased
>>     * merged
>> 
>> The existence (and it being the default) of "merge --ff" makes that
>> somewhat difficult, but in those cases we could and probably should just
>> also say "advanced" (or whatever), since that's what happened, ditto a
>> noop rebase.
>
> I already thought about it and I don't think so. The word "advanced"
> doesn't hint where, how much, or how quickly, could very well be just
> one commit forward.

> 
> On Fri, Jun 25 2021, Felipe Contreras wrote:
> 
> > Ævar Arnfjörð Bjarmason wrote:
> >> 
> >> On Thu, Jun 24 2021, Felipe Contreras wrote:
> >> 
> >> > Philip Oakley wrote:
> >> >> On 24/06/2021 20:05, Felipe Contreras wrote:
> >> >> > Philip Oakley wrote:
> >> >> >> Hi Felipe,
> >> >> >> On 24/06/2021 15:31, Felipe Contreras wrote:
> >> >> >>> Philip Oakley wrote:
> >> >> >>>> On 21/06/2021 18:52, Felipe Contreras wrote:
> >> >> >>>>> --- a/Documentation/git-pull.txt
> >> >> >>>>> +++ b/Documentation/git-pull.txt
> >> >> >>>>> @@ -41,16 +41,41 @@ Assume the following history exists and the current branch is
> >> >> >>>>>  ------------
> >> >> >>>>>  	  A---B---C master on origin
> >> >> >>>>>  	 /
> >> >> >>>>> -    D---E---F---G master
> >> >> >>>>> +    D---E master
> >> >> >>>>>  	^
> >> >> >>>>>  	origin/master in your repository
> >> >> >>>>>  ------------
> >> >> >>>>>  
> >> >> >>>>>  Then "`git pull`" will fetch and replay the changes from the remote
> >> >> >>>>>  `master` branch since it diverged from the local `master` (i.e., `E`)
> >> >> >>>>> -until its current commit (`C`) on top of `master` and record the
> >> >> >>>>> -result in a new commit along with the names of the two parent commits
> >> >> >>>>> -and a log message from the user describing the changes.
> >> >> >>>>> +until its current commit (`C`) on top of `master`.
> >> >> >>>>> +
> >> >> >>>>> +After the remote changes have been synchronized, the local `master` will
> >> >> >>>>> +be fast-forwarded to the same commit as the remote one, therefore
> >> >> >>>> Perhaps s/be fast-forwarded/have been 'fast-forward'ed/ ?
> >> >> >>> No, there's multiple steps:
> >> >> >> My key point was to 'quote' the fast-forward term.
> >> >> > fast-forward is an English word [1], there's no need to quote it as if
> >> >> > it weren't.
> >> >> 
> >> >> You appear to be arguing that your "explain what is a fast-forward"
> >> >> (subject line of the patch) doesn't need, within the patch, to explain
> >> >> that it is about the term "fast-forward", being used in a Git specific
> >> >> way...
> >> >
> >> > When you are trying to explain the meaning of a word it's generally
> >> > better to not use that word in the explanation. For example if you are
> >> > trying to explain "recursion", but you use "recursion" in the
> >> > explanation, that kinds of defeats the purpose.
> >> >
> >> > So yes, in the sentence "the local `master` will be fast-forwarded to
> >> > the same commit as the remote one", the verb "fast-forwarded" can easily
> >> > be replaced with "advanced" and no meaning would be lost.
> >> >
> >> > The meaning of this "fast-forward" verb is the same as when you
> >> > fast-forward a tape, and is not git-specific.
> >> 
> >> Using quotes for a term like 'fast-forward' or some made up word like
> >> 'qibbix' doesn't just serve the purpose of clarifying which ones are in
> >> the dictionary, but also to establish that the quoted word is jargon
> >> within the context of the documentation.
> >> 
> >> If I invent a new and exciting way to cut grass I might say my new
> >> machine 'shaves' the grass. The word "shave" is something I assume
> >> everyone knows, but I'm making it clear that I'm referring to the
> >> exciting mode of operation of my new death machine.
> >> 
> >> 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.

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

> >> This isn't something for your patch, but I wonder more generally if we
> >> shouldn't consider moving away from the term entirely, and just say a
> >> branch was one of:
> >> 
> >>     * advanced (or some other such term, forwarded?)
> >>     * rebased
> >>     * merged
> >> 
> >> The existence (and it being the default) of "merge --ff" makes that
> >> somewhat difficult, but in those cases we could and probably should just
> >> also say "advanced" (or whatever), since that's what happened, ditto a
> >> noop rebase.
> >
> > I already thought about it and I don't think so. The word "advanced"
> > doesn't hint where, how much, or how quickly, could very well be just
> > one commit forward.
> 
> Hrm, we use fast-forward for N commits advanced, including N=1, or
> perhaps I'm misunderstanding you.

> > This is one of those rare occasions where I think the git project chose
> > the perfect word.
> 
> 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.

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

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

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

> Yes, but regardless of that for whatever reason it's already part of the
> culture, and people are using fast-forward irrespective of the original
> meaning:
> 
>   "They fast-forward to present day ten years later, where he has been
>   hospitalized and is on life support." [1]
> 
>   "So then fast-forward to now and, like, six months ago, they found the
>   script and called me up." [2]

> On Mon, Jun 21, 2021 at 11:52 AM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> >
> > +                "If unsure, run \"git pull --no-rebase\".\n"
> 
> I don't think the message should recommend merging over rebasing;

>
> Alex Henrie wrote:
> > On Mon, Jun 21, 2021 at 11:52 AM Felipe Contreras
> > <felipe.contreras@gmail.com> wrote:
> > >
> > > +                "If unsure, run \"git pull --no-rebase\".\n"
> >
> > I don't think the message should recommend merging over rebasing;
>
> This is the default strategy.

> > The eventual goal is to get rid of the default here and make the user
> > make an educated choice, which does imply some work on the user's
> > part, but it avoids the massive headaches created by users merging
> > without understanding what they're doing.
>
> Indeed, but any minute change in git's UI is a gargantuan task that
> takes several years--or even decades--to accomplish, if it ever happens.
> I started this patch in 2013, and here we are.

> On Mon, Jun 21, 2021 at 12:51 PM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> >
> > Alex Henrie wrote:
> > > On Mon, Jun 21, 2021 at 11:52 AM Felipe Contreras
> > > <felipe.contreras@gmail.com> wrote:
> > > >
> > > > +                "If unsure, run \"git pull --no-rebase\".\n"
> > >
> > > I don't think the message should recommend merging over rebasing;
> >
> > This is the default strategy.
> 
> Yes, but it shouldn't be,

> > > The eventual goal is to get rid of the default here and make the user
> > > make an educated choice, which does imply some work on the user's
> > > part, but it avoids the massive headaches created by users merging
> > > without understanding what they're doing.
> >
> > Indeed, but any minute change in git's UI is a gargantuan task that
> > takes several years--or even decades--to accomplish, if it ever happens.
> > I started this patch in 2013, and here we are.
> 
> Although what needs to be done had been envisioned by some as early as
> 2013, the warning has only been around since Git 2.27 (released in
> June 2020), and it was only restricted to pulls where fast-forwarding
> is impossible in Git 2.31 (released in March 2021). The good news is
> that (unless I'm mistaken) there are no more changes that need to be
> made prior to changing the message from from "advise" to "die".

>
> Alex Henrie wrote:
> > On Mon, Jun 21, 2021 at 12:51 PM Felipe Contreras
> > <felipe.contreras@gmail.com> wrote:
> > >
> > > Alex Henrie wrote:
> > > > The eventual goal is to get rid of the default here and make the user
> > > > make an educated choice, which does imply some work on the user's
> > > > part, but it avoids the massive headaches created by users merging
> > > > without understanding what they're doing.
> > >
> > > Indeed, but any minute change in git's UI is a gargantuan task that
> > > takes several years--or even decades--to accomplish, if it ever happens.
> > > I started this patch in 2013, and here we are.
> >
> > Although what needs to be done had been envisioned by some as early as
> > 2013, the warning has only been around since Git 2.27 (released in
> > June 2020), and it was only restricted to pulls where fast-forwarding
> > is impossible in Git 2.31 (released in March 2021). The good news is
> > that (unless I'm mistaken) there are no more changes that need to be
> > made prior to changing the message from from "advise" to "die".
>
> There is *a lot* that needs to be done.
>
>  1. Update the documentation
>  2. Add a --merge option (instead of the ackward --no-rebase)
>  3. Fix all the wrong behavior with --ff, --no-ff, and -ff-only
>  4. Add a pull.mode configuration
>  5. Add a configuration for the mode in which we want to die
>  6. Fix inconsistencies in the UI

> > > Although what needs to be done had been envisioned by some as early as
> > > 2013, the warning has only been around since Git 2.27 (released in
> > > June 2020), and it was only restricted to pulls where fast-forwarding
> > > is impossible in Git 2.31 (released in March 2021). The good news is
> > > that (unless I'm mistaken) there are no more changes that need to be
> > > made prior to changing the message from from "advise" to "die".
> >
> > There is *a lot* that needs to be done.
> >
> >  1. Update the documentation
> >  2. Add a --merge option (instead of the ackward --no-rebase)
> >  3. Fix all the wrong behavior with --ff, --no-ff, and -ff-only
> >  4. Add a pull.mode configuration
> >  5. Add a configuration for the mode in which we want to die
> >  6. Fix inconsistencies in the UI
> 
> I agree with you that the documentation should be updated when the
> change is made (#1),

> > In the meantime there's no reason to have subpar documentation.
> 
> My only serious objection to this patch is the instruction to merge if
> you don't know what to do instead of asking the repository maintainer
> what to do or reading the Git documentation. I don't have a strong
> opinion on the rest of the patch.

>
> My only serious objection to this patch is the instruction to merge if
> you don't know what to do instead of asking the repository maintainer
> what to do or reading the Git documentation. I don't have a strong
> opinion on the rest of the patch.

>
> On Mon, Jun 21, 2021 at 8:15 PM Alex Henrie <alexhenrie24@gmail.com> wrote:
> >
> > My only serious objection to this patch is the instruction to merge if
> > you don't know what to do instead of asking the repository maintainer
> > what to do or reading the Git documentation. I don't have a strong
> > opinion on the rest of the patch.
>
> You're not alone, Alex; I objected to that part as well.  (See e.g.
> https://lore.kernel.org/git/CABPp-BF4rXBOKsn8bG6y3QUEtNVV9K2Pk5NmwrU5818CqhRt_Q@mail.gmail.com/
> and various other emails in that thread, ending with "agree to
> disagree" later).  I still object to it as I did then.

>
> On Tue, Jun 22, 2021 at 9:06 AM Elijah Newren <newren@gmail.com> wrote:
> >
> > On Mon, Jun 21, 2021 at 8:15 PM Alex Henrie <alexhenrie24@gmail.com> wrote:
> > >
> > > My only serious objection to this patch is the instruction to merge if
> > > you don't know what to do instead of asking the repository maintainer
> > > what to do or reading the Git documentation. I don't have a strong
> > > opinion on the rest of the patch.
> >
> > You're not alone, Alex; I objected to that part as well.  (See e.g.
> > https://lore.kernel.org/git/CABPp-BF4rXBOKsn8bG6y3QUEtNVV9K2Pk5NmwrU5818CqhRt_Q@mail.gmail.com/
> > and various other emails in that thread, ending with "agree to
> > disagree" later).  I still object to it as I did then.
>
> Thanks for the link, and sorry for not having followed this
> conversation closely enough to have seen your previous replies. While

> On Tue, Jun 22, 2021 at 2:22 PM Alex Henrie <alexhenrie24@gmail.com> wrote:
> >
> > On Tue, Jun 22, 2021 at 9:06 AM Elijah Newren <newren@gmail.com> wrote:
> > >
> > > On Mon, Jun 21, 2021 at 8:15 PM Alex Henrie <alexhenrie24@gmail.com> wrote:
> > > >
> > > > My only serious objection to this patch is the instruction to merge if
> > > > you don't know what to do instead of asking the repository maintainer
> > > > what to do or reading the Git documentation. I don't have a strong
> > > > opinion on the rest of the patch.
> > >
> > > You're not alone, Alex; I objected to that part as well.  (See e.g.
> > > https://lore.kernel.org/git/CABPp-BF4rXBOKsn8bG6y3QUEtNVV9K2Pk5NmwrU5818CqhRt_Q@mail.gmail.com/
> > > and various other emails in that thread, ending with "agree to
> > > disagree" later).  I still object to it as I did then.
> >
> > Thanks for the link, and sorry for not having followed this
> > conversation closely enough to have seen your previous replies. While
> 
> No worries, you were trying to be a good citizen by reviewing patches,
> and the patches didn't come with links to the old threads

> > > Thanks for the link, and sorry for not having followed this
> > > conversation closely enough to have seen your previous replies. While
> >
> > No worries, you were trying to be a good citizen by reviewing patches,
> > and the patches didn't come with links to the old threads
>
> That's not true. This patch series [1] came with a link to the previous
> patch series [2].
>
> I didn't, cannot, and shouldn't contain hundreds of links to the hundres
> of responses to this topic over the past 10 years.

> On Tue, Jun 22, 2021 at 9:18 PM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> >
> > Elijah Newren wrote:
> > > On Tue, Jun 22, 2021 at 2:22 PM Alex Henrie <alexhenrie24@gmail.com> wrote:
> > > >
> ....
> > > > Thanks for the link, and sorry for not having followed this
> > > > conversation closely enough to have seen your previous replies. While
> > >
> > > No worries, you were trying to be a good citizen by reviewing patches,
> > > and the patches didn't come with links to the old threads
> >
> > That's not true. This patch series [1] came with a link to the previous
> > patch series [2].
> >
> > I didn't, cannot, and shouldn't contain hundreds of links to the hundres
> > of responses to this topic over the past 10 years.
> 
> Sorry for being unclear; by links I meant either direct or indirect
> ones.  Your series came with a link to the previous series.  The
> previous series, however, only contained a link to a series you were
> basing upon rather than to a series which contained the changes you
> were resubmitting.  Thus, following the links in each submission would
> not get you back to the old discussions (I double checked).

> Also, this particular point was not meant as a critique of your
> current submission.  I don't even think it's all that big a deal for
> the previous submission either (it's an easy oversight to make given
> that Junio submitted a portion of one of your old series).  My point
> was simply that Alex didn't need to feel bad for not having been aware
> of all the old discussions; even if he had tried to dive deep by
> recursively following all the links, he wouldn't find it.

> On Mon, Jun 21, 2021 at 8:15 PM Alex Henrie <alexhenrie24@gmail.com> wrote:
> >
> > My only serious objection to this patch is the instruction to merge if
> > you don't know what to do instead of asking the repository maintainer
> > what to do or reading the Git documentation. I don't have a strong
> > opinion on the rest of the patch.
> 
> You're not alone, Alex; I objected to that part as well.  (See e.g.
> https://lore.kernel.org/git/CABPp-BF4rXBOKsn8bG6y3QUEtNVV9K2Pk5NmwrU5818CqhRt_Q@mail.gmail.com/
> and various other emails in that thread, ending with "agree to
> disagree" later).  I still object to it as I did then.

> > You're not alone, Alex; I objected to that part as well.  (See e.g.
> > https://lore.kernel.org/git/CABPp-BF4rXBOKsn8bG6y3QUEtNVV9K2Pk5NmwrU5818CqhRt_Q@mail.gmail.com/
> > and various other emails in that thread, ending with "agree to
> > disagree" later).  I still object to it as I did then.
>
> You made your disagreement known in [1], I responded to it with a
> devastating argument in [2], and you immediately withtdrew from the
> discussion in [3] without engaging my argument at all.

> > I'm curious whether it'll just be resubmitted again multiple times,
> > eventually with a cover letter that repeats something along the lines
> > of "these are the non-controversial changes from last-year series
> > which...don't have any reason not to be merged."
>
> The fact that **one** person was not 100% on board with a change doesn't
> make it controversial.

> On Tue, Jun 22, 2021 at 6:09 PM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> >
> > Elijah Newren wrote:
> ...
> > > You're not alone, Alex; I objected to that part as well.  (See e.g.
> > > https://lore.kernel.org/git/CABPp-BF4rXBOKsn8bG6y3QUEtNVV9K2Pk5NmwrU5818CqhRt_Q@mail.gmail.com/
> > > and various other emails in that thread, ending with "agree to
> > > disagree" later).  I still object to it as I did then.
> >
> > You made your disagreement known in [1], I responded to it with a
> > devastating argument in [2], and you immediately withtdrew from the
> > discussion in [3] without engaging my argument at all.
> 
> I didn't find anything new or persuasive in your rehashing of your
> arguments.

> > > I'm curious whether it'll just be resubmitted again multiple times,
> > > eventually with a cover letter that repeats something along the lines
> > > of "these are the non-controversial changes from last-year series
> > > which...don't have any reason not to be merged."
> >
> > The fact that **one** person was not 100% on board with a change doesn't
> > make it controversial.
> 
> This is a disconcerting response.

> > You made the conscious choice to withdraw from the discussion
> > immediately, so just like a person who abandons an election cycle and
> > decides not to vote, you are leving the future of the matter in the
> > hands of others.
> 
> This is quite a disappointing argument.  If this position were to be
> accepted broadly within the project, it would suggest scorched-earth
> last-man standing tactics -- just arguing until the other side runs
> out of energy.  If that was used to determine our forward strategy,
> it'd result in a massive waste of energy, people feeling drained and
> losing motivation to contribute, some people just deciding to leave
> the project, and a myriad of other negative outcomes.

>
> On Tue, Jun 22, 2021 at 2:22 PM Alex Henrie <alexhenrie24@gmail.com> wrote:
> >
> > While
> > we're on the subject, do you have any thoughts on what (if anything)
> > more should be done before making the switch to aborting instead of
> > merging with a warning in `git pull`?
>
> I think Junio already answered that over here:
> https://lore.kernel.org/git/xmqq360h8286.fsf@gitster.c.googlers.com/
> (he discussed it multiple times in that thread, but hopefully that's a
> good enough example).

> On Tue, Jun 22, 2021 at 8:20 PM Elijah Newren <newren@gmail.com> wrote:
> >
> > On Tue, Jun 22, 2021 at 2:22 PM Alex Henrie <alexhenrie24@gmail.com> wrote:
> > >
> > > While
> > > we're on the subject, do you have any thoughts on what (if anything)
> > > more should be done before making the switch to aborting instead of
> > > merging with a warning in `git pull`?
> >
> > I think Junio already answered that over here:
> > https://lore.kernel.org/git/xmqq360h8286.fsf@gitster.c.googlers.com/
> > (he discussed it multiple times in that thread, but hopefully that's a
> > good enough example).
> 
> Wow, if I understand correctly from that message, Junio wouldn't mind
> making the switch right away. That's very encouraging.

> On Wed, Jun 23, 2021 at 12:19 PM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> >
> > Similarly, until "git pull" does something sensible by default (which
> > isn't the case now), these debates will continue, and there's value in
> > them.
> 
> At this point, I'm inclined to push for s/advise/die/ in pull.c in the
> next release, without a transitional period, just to end the argument
> over how to best explain the current awkward situation. (I'm sure
> there will be more arguments after that, but hopefully they won't be
> as tiresome.)

>
> Alex Henrie wrote:
> > On Wed, Jun 23, 2021 at 12:19 PM Felipe Contreras
> > <felipe.contreras@gmail.com> wrote:
> > >
> > > Similarly, until "git pull" does something sensible by default (which
> > > isn't the case now), these debates will continue, and there's value in
> > > them.
> >
> > At this point, I'm inclined to push for s/advise/die/ in pull.c in the
> > next release, without a transitional period, just to end the argument
> > over how to best explain the current awkward situation. (I'm sure
> > there will be more arguments after that, but hopefully they won't be
> > as tiresome.)
>
> Give it a try. You will inevitably stumble upon all the problems I
> already fixed.

> On Wed, Jun 23, 2021 at 11:55 PM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> >
> > Alex Henrie wrote:
> > > On Wed, Jun 23, 2021 at 12:19 PM Felipe Contreras
> > > <felipe.contreras@gmail.com> wrote:
> > > >
> > > > Similarly, until "git pull" does something sensible by default (which
> > > > isn't the case now), these debates will continue, and there's value in
> > > > them.
> > >
> > > At this point, I'm inclined to push for s/advise/die/ in pull.c in the
> > > next release, without a transitional period, just to end the argument
> > > over how to best explain the current awkward situation. (I'm sure
> > > there will be more arguments after that, but hopefully they won't be
> > > as tiresome.)
> >
> > Give it a try. You will inevitably stumble upon all the problems I
> > already fixed.
> 
> Patch sent.

> > In the meantime what's the problem with v2?
> 
> I think that setting pull.rebase on a per-repository basis (instead of
> globally or per-invocation) makes for the easiest workflow in the
> majority of cases, so I would prefer to continue to recommend that to
> users primarily, but I don't have a strong opinion.