On Mon, Jul 10, 2023 at 06:30:04PM +0200, Uwe Brauer wrote:

> While in mercurial «hg fetch» is equivalent to «hg pull» and «hg merge»
> it seems that «git pull --no-ff» is not equivalent to 
> «git fetch» and «git merge».

This might be wrong expectations.
I'll try to explain in simple words.

In a VCS which uses cryptographic hashes to refer to commits, a line of
history may be fully contained in another, say

  A --> B --> C --> D

fully contains

  A --> B


  A --> B --> C

but not, for instance,

  A --> B --> X

A branch fully contained in some other branch is said to be eligible for
fast-forwarding to that containing (enclosing) branch. Why is that?
Because if we, say, have that A --> B line of commits on some branch,
and want that branch to now become A --> B --> C --> D, there's no real need
to _actually merge_ that C --> D bit: we can instead just update the branch to
point directly at D, with not merge commit involved.

Git defaults to this fast-forward behavior in every place merging is involved,
and `git pull` is one of such places. Going back to our example, if you
locally have your "master" to contain A --> B, and "master" in the remote repo
contains A --> B --> C --> D, pulling from that branch will by default to a
fast-forward merge. The "--no-ff" command-line option for `git pull` is
actually passed by that command to `git merge` it eventually calls, and forces
the latter to not do a fast-forward and instead record a true merge, resulting
in a merge commit recorded, which has two parents: B and D.

Whether to always opt for "true" merges even if they are "trivial" is an open
question. Some workflows explicitly make use of it. My opinion is that it
should only be used when what it offers is explicitly understood and sought.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Reply via email to