resurrect a changeset

Christophe de Vienne cdevienne at gmail.com
Tue Dec 10 02:34:35 CST 2013


Le 10/12/2013 00:33, Pierre-Yves David a écrit :
> On 12/07/2013 05:14 AM, Christophe de Vienne wrote:
>> Hi,
>>
>> Yesterday I needed to remove the obsolescence marker of a changeset I
>> clumsily killed.
>> "hg touch" was not an option because the changeset was comming from a
>> central repository and I did not want to change it there.
>
> I'm not sure to see why you would not want to touch your original
> changeset ? Was it public ? Was it not yours ?

It was a draft changeset that wat already pushed to review, and I did
not want to add confusion by adding a no-change cset just because I made
mistakes on my sid.

And at the moment I saw the mistake, the rollback was not an option
anymore because I had done other commands meanwhile.

What I basically needed to do was getting in line with the central
repository on a handfull of cset, and the only remaining bit that
stopped me to do so is un-pruning a single changeset.

>
>> The only way to do so is, at the moment, to remove .hg/store/obsstore
>> and re-pull,
>
> Well it (may) sound like you want an undo mechanism here. And you may
> look in the direction of multi-undo for a proper UI
>
>     https://bitbucket.org/hstuart/hg-multiundo
I had this one in my radar not long ago, I will have a look.

>
> ( The `hg rol#####` command would work here but I do not recommand you
> to rely on it)
>
>> realize the actual need to un-kill a cset should not be a common
>> use-case,
> The command to unkill and changeset exist. It is called `hg touch`.
>
> What you want here is a way to strip changeset. This will never be
> recommanded and never be a first class citizen. The DVCS world is
> happen only and relying on striping stuff in always a bad idea.
>
> Stripping marker may be sometime necessary for maintenance purpose.
> But it will probably stick into a debug command.

I fully agree.

>
>
>> Speaking with Pierre-Yves made it clear it is not a high priority task,
>> so I am willing to give it a try and write such a command.
>>
>> So I come here for advice :
>> - Where should I start : patch evolve ? write my own extension ?
>
> I will accept a patch for evolve
>
>> - Which APIs can I use to access the obsstore ?
>
> Looks at mercurial/obsolescence.py
>
>> - anything else I should know before starting ?
>
> Make it a debug command, focus on stripping marker.

Would adding a "--strip-marker" option to "touch" be an acceptable
solution ?


>
> read this:
>
> - http://mercurial.selenic.com/wiki/ContributingChanges
> - http://mercurial.selenic.com/wiki/LockingDesign
>
> Have fun in your journey.

Thanks :-)


Christophe


More information about the Mercurial-devel mailing list