Re: How to merge and push?

[John W. Eaton]

On  8-Mar-2010, Jaroslav Hajek wrote:

| On Mon, Mar 8, 2010 at 7:55 AM, S ren Hauberg <address@hidden> wrote:
| > Hi All
| >
| > I have a stupid Mercurial question... I just pushed a small change to
| > 'dim-vector.h'. When I first tried to push I was told that this would
| > create to upstream branches, so I did a
| >
| >  hg pull ssh://address@hidden/octave
| >  hg merge
| >
| > which told me I had to commit to complete the merge. So, I did a
| >
| >  hg commit -m "Merged with upstream"
| >
| > I then pushed my change to 'dim-vector.h' without problems. Now, I see
| > that the tip is
| >
| >  http://hg.savannah.gnu.org/hgweb/octave/rev/b40a5fd3af41
| >
| > which corresponds to the merge i performed. I guess this means I must
| > have screwed up somehow as it doesn't seem sensible that the upstream
| > repository should be bothered with how and when I merge stuff.
| >
| > So, my question is: what did I do wrong and how should I have done?
| >
| > Thanks,
| > S ren
| >
| >
| 
| We had an agreement to keep the changes linear; that effectively
| implies avoiding branches & merges. However, for mercurial developers
| branches & merges are apparently the "normal" way to do development
| (cf. for instance
| http://hg.intevation.org/mercurial/crew/graph/87fce8c5e29d), so
| mercurial will often suggest you do a merge.
| 
| There are two tools for linearizing the changes:
| 1. hg rebase
| 2. mercurial queues
| 
| 1. Is simpler. In newer versions you can just do hg pull -u --rebase
| and it should do the right thing. "hg help rebase" shows more.
| 
| 2. Is more powerful. Just keep your change in the queue (you can even
| put committed changes back in the queue) and upon pushing upstream,
| you do
| hg qpop (-a)
| hg pull -u
| hg qpush (-a)
| # possibly fix conflict
| # hg qref
| hg qfin qtip (or -a)
| hg push
| 
| if someone happened to push between your push & pull, you need to
| repeat the procedure (+hg qimport).
| 
| I see at least one major disadvantage to the strictly linear policy:
| When I make changes to some low-level files (in liboctave), a
| compilation cascade occurs (this is normal).
| When I want to linearize the change against new upstream changes, I
| need to pop it, pull from upstream and push it again. Then, the
| compilation cascade occurs again, because all files are touched.
| Sometimes this is a real hassle. Merge doesn't suffer from this
| problem.
| 
| On the contrary, I don't see any real advantages in keeping the
| changes linear. Does anyone else?

I prefer to keep the public archive linear.

S ren's recent merge is not too bad, but I find things like
this changeset:

  http://hg.savannah.gnu.org/hgweb/octave/rev/97aa01a85ea4

to be confusing.  When I look at the archive history around this time
with "hg view", I see the attached output.

I guess I just don't have the brainpower to figure out what is
happening here, and I don't want to have to think about whether a
changeset like this is just a merge, or is doing something else
like removing changes that were already made.  I just want to avoid
the confusion in the public archive.

jwe