"Push creates new remote heads" and my humble workflow (kind of dummy question)

[Pierre-Yves David]

On 7/16/20 11:28 AM, Victor Sudakov wrote:
> Manuel Jacob wrote:
> 
> [dd]
> 
>>>>
>>>> Before the merge, you had two heads. To get one head, you can merge
>>>> them.
>>>
>>> Where did I have the two heads physically? There was one head at home,
>>> and
>>> one head at work, that's true. But I never allowed to create two heads
>>> in the cloud.
>>
>> Suppose we start in a situation where you have only one head X in the home,
>> work and cloud repos.
>>
>> Then, in the work repo, you create A on X. A is now the single head in the
>> work repo. Before driving home, you forget to push.
> 
> OK, I see.
> 
>>
>> Then, in the home repo, you create B on X. B is now the single head in the
>> home repo. You push to the central repo, which then also has a single head
>> B.
>>
>> Then, in the work repo, you pull. Now you have two heads A and B in the
>> repo.
> 
> If I "pull -u" in the work repo, will my working directory be updated to
> B? Probably it will, because i've pulled from the central repo, right?
> Is it a good idea to always run "pull -u"? (which I do).
> 
>>
>>> I want to fix my workflow somehow so that only one head (in all the
>>> repos) exists at a time.
>>
>> In your case, as the only person working on the repo, you could avoid the
>> situation by always pulling before committing and always pushing before
>> switching machines.
> 
> Can I enforce this discipline?

You can make sure you alway pull before committing by adding a hook in 
your config.


[hooks]
pre-commit=hg pull -u

(hook provided without any testing, so migh need adjustment to work)

> 
>>
>> If you have the rebase extension enabled, you can pass "--rebase" to "hg
>> pull", which will linearize the changesets after pulling.
> 
> This sounds interesting. Can you please explain on the X,A,B example
> above, what "pull --rebase" will do?
> 
> "rebase working directory to branch head" does not sound exactly clear.
> Which branch? I don't have branches, just accidentally create two heads
> from time to time.

Has soon are you start having multiple heads, you have topological branches.

In your case you have two heads B and C. each on they own "topological 
branch"


A---B
  \
   \-C

Lets says you committed "C" locally and pulled "B". (so you working copy 
is on changeset of C).

rebase will "recreate" C (as a new changeset, C') on top of B. So the 
result will be:

A---B---C'

> 
> [dd]
> 
>>
>>> For now I see that "hg diff -c 134" and "hg diff -c 132" look identical.
>>> The same can be said about "hg log -r132 -p" and "hg log -r134 -p" -
>>> identical except for the commit message and some metadata.  This is
>>> confusing, the final tree (viewed with "hg log -p" or whatever) looks
>>> like
>>> the changes were applied twice but in fact they were not.
>>
>> I don’t know how you created the merge changesets, but when using a commit
>> message like "Merge heads.", there will be no duplication in the message.
> 
> It's not the duplication in the message that I object to, it's the
> duplication in the diff ("hg log -p" output and such become confusing).
> 
>>
>> In the future, hopefully Mercurial gets more useful diffs for merges. I know
>> that work on this was started, but I don’t think there’s something ready to
>> use.
> 

-- 
Pierre-Yves David