resurrect a changeset

[Christophe de Vienne]

Le 10/12/2013 10:02, Pierre-Yves David a écrit :
> On 12/10/2013 12:34 AM, Christophe de Vienne wrote:
>> 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.
>
> Partial cloning should be able to work here (you reclone your local
> repo with just the subset you want).
> However obsolescence marker exchange is not smart enough yet. This
> will eventuallu be fixed
>
>>>
>>>> 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 ?
>
> No way.

Fair enough :-)

>
> ("prune" does not really have a debug prefix.

I am not sure I understand what you mean here.

> We may wan to look at adding some smartess into strip so it remove
> marker up to the next known successors.
> But I not sure I want to see strip gaining more usage.

Sounds like a not so good idea to me. Having a specific debug command is
better IMO.


Christophe