How to merge and push?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

How to merge and push?

Søren Hauberg
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://[hidden email]/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

Reply | Threaded
Open this post in threaded view
|

Re: How to merge and push?

Michael Goffioul
On Mon, Mar 8, 2010 at 6:55 AM, Søren Hauberg <[hidden email]> 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://[hidden email]/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?

What I do is using patch queue (see for instance
http://mercurial.selenic.com/wiki/MqExtension).

So when I want to merge, I do (assuming the target patch
is at the bottom of the stack):

hg qpop
hg pull -r tip
hg update -r tip
hg qpush
(edit ChangeLog files and move entries at the correct location)
hg qrefresh
hg delete -r <patch_name>
hg push -r tip

I nobody pushes something between the pull and the push
command, then it works fine.

Michael.

Reply | Threaded
Open this post in threaded view
|

Re: How to merge and push?

Jaroslav Hajek-2
In reply to this post by Søren Hauberg
On Mon, Mar 8, 2010 at 7:55 AM, Søren Hauberg <[hidden email]> 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://[hidden email]/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 | Threaded
Open this post in threaded view
|

Re: How to merge and push?

John W. Eaton
Administrator
On  8-Mar-2010, Jaroslav Hajek wrote:

| On Mon, Mar 8, 2010 at 7:55 AM, S ren Hauberg <[hidden email]> 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://[hidden email]/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


hg-view.png (113K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to merge and push?

Jaroslav Hajek-2
2010/3/15 John W. Eaton <[hidden email]>:

> On  8-Mar-2010, Jaroslav Hajek wrote:
>
> | On Mon, Mar 8, 2010 at 7:55 AM, S ren Hauberg <[hidden email]> 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://[hidden email]/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

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

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

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

Reply | Threaded
Open this post in threaded view
|

Re: How to merge and push?

Rik-5
In reply to this post by Søren Hauberg


>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: How to merge and push?

John W. Eaton
Administrator
On 16-Mar-2010, Rik wrote:

| 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.

OK, that's good to know.  If mercurial could tell me that, then I
might be more comfortable with a non-linear revision history.  But as
it is now, it is not possible to tell whether this is the case, and
for a merge like the one you made, the merge changeset is large, and
it is difficult to look at that and know whether some of the changes
undid other changes (i.e., the person doing the merge had to decide
which branch to use and selected the wrong one, or made some other
incorrect edit when merging).  If I don't know what happened during
the merge, I have no confidence that it was done correctly.

Yes, it is possible that any given changeset can undo someone elses
changes, or be incorrect in some other way, but typically they are
small, confined to a single concept, and relatively easy to verify.

Do any of the current DVCSs have a feature like you describe, that
will tell if a merge was clean or required conflict resolution?  Does
no one else see a use for a feature like that?  If not, why not?

And, in case it isn't clear, I'm not faulting you for the merge you
made.  I don't think we alerted you to the preference before you did
it, and in any case, it didn't cause any real harm.

| 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.

I'm open to reconsidering in the future, but I think it is relatively
easy to keep the public archive linear for now, and that makes it
easier to understand what the changes are doing.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: How to merge and push?

Rik-5
In reply to this post by Søren Hauberg

> | 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.
>
> OK, that's good to know.  If mercurial could tell me that, then I
> might be more comfortable with a non-linear revision history.  But as
> it is now, it is not possible to tell whether this is the case, and
> for a merge like the one you made, the merge changeset is large, and
> it is difficult to look at that and know whether some of the changes
> undid other changes (i.e., the person doing the merge had to decide
> which branch to use and selected the wrong one, or made some other
> incorrect edit when merging).  If I don't know what happened during
> the merge, I have no confidence that it was done correctly.
True.  One way is to use 'hg log -v' and look for the line beginning with
'files:'.  This can profitably be combined with '-m' to look only at merges
in the log.  The latest merge using 'hg log -m -v' shows:
changeset:   10404:b40a5fd3af41
parent:      10403:69ecfbffcf4f
parent:      10402:9f2bf537a651
user:        Soren Hauberg <[hidden email]>
date:        Sun Mar 07 22:26:45 2010 -0800
description:
Merged with upstream

There is no line with 'files:' so this merge was strictly for Mercurial's
benefit.

The merge proceeding this was
changeset:   9264:be7d8132c139
parent:      9263:9eb6e8f2b937
parent:      9262:de255681c85f
user:        Soren Hauberg <[hidden email]>
date:        Tue May 26 18:59:12 2009 +0200
files:       scripts/ChangeLog
description:
Resolve ChangeLog conflict

This just happens to show how using a ChangeLog file creates a merge action
that really isn't there.

>
> Do any of the current DVCSs have a feature like you describe, that
> will tell if a merge was clean or required conflict resolution?  Does
> no one else see a use for a feature like that?  If not, why not?
It seems like it would be a good idea to me, but I don't see offhand that
anyone has implemented this.

--Rik