> 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 G
>>> "CS" == Chris Stone writes:
> 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 |fa
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
>>> "KK" == Konstantin Khomoutov 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 ex
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.
Hi
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».
I run an experiment. Set up a local git server, with a couple of commits.
Cloned it as user1
cloned it as user2
User1 pushes a (non c
