Re: [auto merged failed]

[Uwe Brauer]

>>> "TH" == Tassilo Horn <tsdh@gnu.org> writes:

Hi 

>>> No, fetch is not bad at all.  It's just "load all changes from the
>>> remote without applying them on my local branches".  And pull is
>>> basically fetch + merge.
>> 
>> Aha, so this is just the other way around as in mercurial.
>> 
>> hg pull -u 
>> 
>> pulls but does not merge

> I think "hg pull" is pretty much like "git fetch".  I'm not exactly sure
> how "hg pull -u" compares to "git pull", though.  

-u is for update [1]. 

> In case you have no local commits which are not on the remote, it
> will update your local branch to the latest commit on the remote.



So  hg pull 

pulls new changesets/commits

While hg pull -u 

Updates to the latest pulled change set/commit.

I think the closest thing is a fast forward in git, although the message
fast forwarding pops up in mercurial if you use bookmarks, which I don't
use. A look at the hg-git Rosetta stone confirms that 

|git fetch| hg pull -u| 




> The interesting question is what happens when you've made a commit
> locally and Alice pushed another commit to the remote.

> With "git pull" it would create a merge commit merging Uwe-commit and
> Alice-commit.  With "git pull --rebase" (which many people configure to
> be the default pull behavior), it would undo Uwe-commit, put
> Alice-commit as top of the branch, and then replay Uwe-commit on top.

> What does "hg pull -u" do in that situation?  The docs are very sparse.

As I said -u just updates. 

So if you use hg pull -u


To pull changesets from remote and you
have already done some changes, on the same branch[2] (!), mercurial
pulls, and then  updates(checkout)
to the latest change set (from remote) and creates what is called an
anonymous head [3], which you see when you run 

hg log -G

So you should then 

    1. merge because anonymous heads are confusing (and decide which
       head to merge to which).

    2. You could of course rebase if you desire (I don't use that
       because I find a graph with merges easier to understand than
       rebased linear graphs).


>> hg fetch
>> 
>> pulls and merges 

> "hg fetch" is a deprecated extension.



Hahah. 

Well there was a discussion about this particular entry in the
documentation some time ago on the mercurial list. It turned that was
written by some mercurial purist who wanted to discourage the use of hg
fetch.

I have also to admit that I don't use hg fetch, because I want more
control over what I am doing. So maybe, after the pull I find out that
my local commit was stupid, in which case I would delete it (hg strip)
and not merge it.

However, especially in covid times I convinced some of my collaborators,
more or less successfully, to use mercurial. Unfortunately  some have
difficulties with the concepts of decentralised version control
systems[4] and merging, so for them

hg fetch [5]

Is a blessing and I was afraid that hg fetch would be removed, that is
however not the case for the foreseeable future.

BTW the same could be said for git pull....


>> Which seems the same as you see.

> Yes, looks correct.

> Bye,
> Tassilo


Regards

Uwe 

Footnotes:
[1]  recall in HG: up update co checkout are all synonyms for the same thing.

[2]  for me that would be named branch, a concept that does not exist in git

[3] a head in mercurial speech is a change set without children, it is
     not a head in the sense of git. (there is no equivalent for
     anonymous heads in git since nameless change set are not really
     allowed as I understand, in mercurial this is possible since a
     branch in mercurial is something different that a branch in git)

[4]  I think this is one of the reasons why subversion is still so
     popular. A lot of people find this model more intuitive.

[5]  To say that again  hg fetch does precisely what git pull does,
     pulls and merges automatically. Of course if there is a merging
     conflict, it will return error, but that can't be avoided.

smime.p7s
Description: S/MIME cryptographic signature