from https://git-scm.com/docs/git-config
pull.ff
By default, Git does not create an extra merge commit when merging a
commit that is a descendant of the current commit. Instead, the tip
of the current branch is fast-forwarded. When set to |false|, this
variable tells Git to create an extra merge commit in such a case
(equivalent to giving the |--no-ff| option from the command line).
When set to |only|, only such fast-forward merges are allowed
(equivalent to giving the |--ff-only| option from the command line).
This setting overrides |merge.ff| when pulling.
if you run git config pull.ff false a git pull will always default to a
merge commit. Use git config --global to set system wide
On 7/10/23 12:01, Uwe Brauer wrote:
"KK" == Konstantin Khomoutov<kos...@bswap.ru> writes:
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
and
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.
So far I had assumed.
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.
But that is where my confusing starts I used the "--no-ff" option and
nevertheless git performed (at least the graphs looks to me like that)
a fast forward.
Is there no way to configure pull that it produces the same graph, as
git fetch+merge?
Mercurial seems to do that and I will ask some mercurial guru how it
does it.
--
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
https://groups.google.com/d/msgid/git-users/bfefb680-d434-4ae4-7eab-f036ffb1edbf%40gmail.com.
