newcomer question not found in the FAQ

[jose miguel hernandez]

I guess you might do 4 different things with it.

You merge and discard, as Steve proposed. This means that although you see
the merge in the graph, in reality the content of the merge revision(rev 6)
is the same as rev 5.

You could clone it as steve proposed too or you could use the strip command
(if mq extension is enabled).

hg strip 3

Anyway, you could do this only if you have not shared your repository with
someone else. Otherwise the changeset might reappear on subsequent sync
operations(pull/push)

you could do a backout of revision 3, this will create another changeset
that undo revision 3 and this could be merged with 5. This do practically
the same as the dummy merge but more verbose (you could state here that the
approach is a dead end... normally you don´t know it in the first place or
you would not have done the commit)

The last option is just leave it there... as an un-merged useless head.

Well, this is what i understand. Of course, others might know other
implications of the dummy merge vs a backout. I think is the same result.

Regards


On Mon, Dec 21, 2009 at 11:22 PM, Steve Borho <steve at borho.org> wrote:

> On Mon, Dec 21, 2009 at 10:59 PM, tristan stag <trstag75 at yahoo.fr> wrote:
> >
> >> hg up 5
> >> hg merge --config ui.merge=internal:local
> >> hg commit
> >
> > I just did that and ended up with the changeset
> > I didn't want (changeset 3) merged with the rest:
> >
> > [nonet at saturn 27.3G ~/example/proj/] $ hg glog | grep -v date | grep -v
> user
> > @    changeset:   6:4a0b60b54ee0
> > |\   tag:         tip
> > | |  parent:      5:d69ac2cb7713
> > | |  parent:      3:21697fa637b5
> > | |  summary:     testing internal:local
> > | |
> > | o  changeset:   5:d69ac2cb7713
> > | |  summary:     even better
> > | |
> > | o  changeset:   4:485cada3297c
> > | |  parent:      2:056a28fae544
> > | |  summary:     Heuristic algo giving very good results
> > | |
> > o |  changeset:   3:21697fa637b5
> > | |  parent:      1:9d83166bce20
> > | |  summary:     No closed formula, heuristic algo giving terribly
> > | |               bad results: example of what not to do
> > | |
> > | o  changeset:   2:056a28fae544
> > |/   summary:     Algo passing all test on data set, moderately fast
> > |
> > o  changeset:   1:9d83166bce20
> > |  summary:     Added data set to test algos
> > |
> > o  changeset:   0:2f01508c3f15
> >   summary:     Initial import
> >
> > This is precisely what I don't want to happen during a merge.
> >
> > I want changeset 3: to never mess with the rest of the repository
> > again (it can either stay there or disappear completely: I don't
> > care as long as it ain't ever merged again with the rest).
> >
> > Ah damn me, I'm really a Mercurial newbie :(
>
> It is merged, but it is not effecting the tip at all.  This is how you
> kill the effects of a dead branch.  You have now officially told
> Mercurial that changeset 3 should not to affect anything after it.
> Normally merges like that are giving commit messages like:  "Killing
> off a bad head".
>
> So, if you are really annoyed by the revision 3 still being in your
> repository, you can do this:
>
> hg clone -r5 repo repo-clean
>
> This will generate a clone with revision 5 and it's ancestors.
> changeset 3 will not be in repo-clean, and if you're happy with it you
> can nuke the original repo.
>
> --
> Steve Borho
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20091221/91cc78c4/attachment.html>