Re: How to merge and push?

[Jaroslav Hajek]

2010/3/15 John W. Eaton <address@hidden>:
> 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.
>

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.

In the present situation, judging by

address@hidden:~/devel/octave/main> hg log -d -90 | grep user: | sort | uniq -c

      9 user:        Ben Abbott <address@hidden>
      1 user:        Carlo de Falco <address@hidden>
     16 user:        David Bateman <address@hidden>
      7 user:        David Grundberg <address@hidden>
    175 user:        Jaroslav Hajek <address@hidden>
    158 user:        John W. Eaton <address@hidden>
      1 user:        Joshua Redstone <address@hidden>, John W.
Eaton <address@hidden>
      1 user:        address@hidden
      1 user:        Jyh-miin Lin <address@hidden>
      1 user:        Marco Atzeri <address@hidden>
      9 user:        Michael Goffioul <address@hidden>
     23 user:        Rik <address@hidden>
      1 user:        Rob Mahurin <address@hidden>
      1 user:        Ryan Rusaw <address@hidden>
      4 user:        Shai Ayal <address@hidden>
      4 user:        Soren Hauberg <address@hidden>
      1 user:        Søren Hauberg <address@hidden>
      1 user:        Tatsuro MATSUOKA <address@hidden>
      1 user:        Thomas Treichl
      1 user:        Thomas Weber <address@hidden>
      5 user:        Thorsten Meyer <address@hidden>

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.

regards

-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz