Bagas Sanjaya wrote: > 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@xxxxxxxxx> > > --- > > 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? Yes, but that's not always possible. The changed documentation is trying to shine a light into when it is possible, when it isn't, and why. -- Felipe Contreras
