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

[Manuel Jacob]

On 2020-07-16 07:20, Victor Sudakov wrote:
> Manuel Jacob wrote:
>> On 2020-07-16 04:09, Victor Sudakov wrote:
>> > Uwe Brauer wrote:
>> > >
>> > >
>> > > > The worst is that I cannot catch what actions cause this situation.
>> > > > Perhaps my forgetting to do "pull -u" before commit, or maybe not.
>> > >
>> > > You could give
>> > >
>> > >
>> > > hg fetch
>> > >
>> > >
>> > > a try.
>> >
>> > This still does not help me understand what is really happening behind
>> > the
>> > scenes: why the same changeset is duplicated in the repository. In other
>> > words, why do I have to merge what's already there.
>> 
>> What do you mean by "duplicated"?
>> 
>> 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.

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.

> 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.

If you have the rebase extension enabled, you can pass "--rebase" to "hg 
pull", which will linearize the changesets after pulling.

> Maybe my many years of CVS/SVN experience are confusing me. Still I
> like DVCS for the possibility to make intermediate commits locally
> before pushing changes to the upstream repo.
> 
>> 
>> 132 and 134 will have the same diff (if there was no merge conflict). 
>> But
>> that doesn’t mean that they are identical.
> 
> Oh.
> 
>> It’s just a result of how
>> Mercurial shows the diff of merges (it shows the difference between 
>> the
>> first parent the merge).
> 
> Very interesting. So because Changeset 134 has two parents, the diff is
> shown in a special way?

Actually, Mercurial by default always shows the diff between the first 
parent and the changeset. Merges aren’t handled specially.

> 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.

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.