Re: How to merge and push?

[Rik]

> 
> I think it's understandable clear from the graph how the changes
> happened. I guess it could be significantly clearer if mercurial was
> able to identify the "mainstream" branch and keep it strictly on the
> left side, instead of letting it zigzag from left to right, so that
> you could clearly see at which point Rik started his changes and at
> which point he merged them.
It would also be clearer if Mercurial identified with a symbol whether
there was a collision during the merge or not.  Nearly 100% of the "merges"
I checked in were only for the benefit of Mercurial.  I did not actually
need to make a choice about which code would stay in the repository and
which would get deleted.  I point this out because in older source code
control systems, like CVS, merging was a perilous process that required a
lot of manual coder intervention.  But Mercurial is using the same word,
merge, for something which is often very benign.  In my case, I made a few
documentation changes while others were working on actual Octave internals.
    As with most changes over such a large code base, the lines I touched
were not changed by others during the time I was making my updates and the
"merge" was really just telling Mercurial to accept my changes.

> 
> that the two of us are the most frequent committers, we have no need
> to abandon our linear policy, especially given that we usually don't
> commit at the same time given the timezone difference.
> 
> But I think you should reconsider that if Octave gets more active 
> contributors.
> 
I agree.  It is not too much trouble to use rebase or patch queues right
now.  But, if you were to put this to a vote it seems that all of the
really big coding projects have voted to move towards distributed source
control systems with non-linear commit trees.

--Rik