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

[Victor Sudakov]

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.

I want to fix my workflow somehow so that only one head (in all the
repos) exists at a time.

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?

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.

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49 at fidonet http://vas.tomsk.ru/