newcomer question not found in the FAQ

[Patrick Mézard]

Le 22/12/09 05:31, Steve Borho a écrit :
> On Mon, Dec 21, 2009 at 10:20 PM, tristan stag <trstag75 at yahoo.fr> wrote:
>> Hi all,
>>
>> I started using Mercurial (coming from Subversion) and
>> I've got a question that I haven't found in the FAQs
>> / Wikis.  I probably overlooked the answers because
>> I'm new and a bit confuzzabled by something simple.
>>
>> I'd like to know the "philosophy" underlying the
>> following problem: what am I supposed to do with
>> a changeset that either broke something or that
>> is simply not working at all, but that I still
>> want to keep as an example of "what not to do"?
>>
>> Here's an example, changeset 3: is bad but I'd still like to keep it.
>>
>> The problem is that altough I manage to go
>> back and start from changeset 2: the changeset 3:
>> is still in there.
>>
>> It's not an issue: ideally I'd like to keep it around,
>> but apparently as soon as I do a merge it gets merged.
>>
>> I know changeset 3: is broken, I'll never ever want to
>> merge it again nor to fix it.  It's an approach that is
>> not working.
>>
>> Ideally I'd like to keep it around as an example of what
>> not to do but removing it altogether would be fine.
>>
>> What am I supposed to do with that changeset 3: ?
>>
>> AFAICT when I did merge the "sh*t hit the fan" and
>> that changeset 3: got merged.
>>
>> (btw Mercurial 1.4.1 on OS X 10.6 and 1.0.1 on a
>> stock Debian Lenny 5.0.3)
>>
>> I guess it comes down to:
>>
>> - what am I supposed to do with a changeset that broke
>>  something but I'd still like to keep around?
>>
>> and:
>>
>> - what am I supposed to do with an approach that simply
>>  didn't work and that I don't necessarily want to keep
>>  around? (I mean: in some case I really couldn't care
>>  less about that changeset, I can either keep it or
>>  delete it once and for all, I don't care as long as
>>  it shall never interfere again with the rest of the
>>  code).
>>
>>
>> [nonet at saturn 27.5G ~/example/proj/] $ hg gl
>> @  changeset:   5:d69ac2cb7713
>> |  tag:         tip
>> |  user:        nonet at saturn.xyp
>> |  summary:     even better
>> |
>> o  changeset:   4:485cada3297c
>> |  parent:      2:056a28fae544
>> |  user:        nonet at saturn.xyp
>> |  summary:     Heuristic algo giving very good results
>> |
>> | o  changeset:   3:21697fa637b5
>> | |  parent:      1:9d83166bce20
>> | |  user:        nonet at saturn.xyp
>> | |  summary:     No closed formula, heuristic algo giving terribly bad
>> | |               results: example of what not to do
>> | |
>> o |  changeset:   2:056a28fae544
>> |/   user:        nonet at saturn.xyp
>> |    summary:     Algo passing all test on data set, moderately fast
>> |
>> o  changeset:   1:9d83166bce20
>> |  user:        nonet at saturn.xyp
>> |  summary:     Added data set to test algos
>> |
>> o  changeset:   0:2f01508c3f15
>>   user:        nonet at saturn.xyp
>>   summary:     Initial import
> 
> hg up 5
> hg merge --config ui.merge=internal:local
> hg commit
> 
> This does a merge, while always selecting the local (changeset 5)
> version of all files.

Actually, it's not enough, you really want:

$ hg up 5
$ hg merge --config ui.merge=internal:local
$ hg revert -a -r .
$ hg commit

Or files added in the other branch will be brought in.

--
Patrick Mézard