octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to merge and push?


From: Jaroslav Hajek
Subject: Re: How to merge and push?
Date: Mon, 8 Mar 2010 08:43:00 +0100

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?

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]