[PATCH 1 of 2] histedit: add stop verb

Augie Fackler raf at durin42.com
Tue Sep 9 11:35:28 CDT 2014

On Sep 9, 2014, at 12:34 PM, David Soria Parra <davidsp at fb.com> wrote:

> Am 9/9/14, 8:57 AM, schrieb Augie Fackler:
>> On Mon, Sep 08, 2014 at 09:35:54AM -0700, David Soria Parra wrote:
>>> # HG changeset patch
>>> # User David Soria Parra <davidsp at fb.com>
>>> # Date 1409941197 -7200
>>> #      Fri Sep 05 20:19:57 2014 +0200
>>> # Node ID e79544cdfb81f88d782e923d96e8ad63303aec94
>>> # Parent  c4b1d0db14c257e9fbb58e0f044c28f12dade3dd
>>> histedit: add stop verb
>>> We are adding a 'stop' verb for histedit. This applies the changes
>>> and drops the user into a shell after committing the changes. This allows to
>>> amend or modify the commit with external tooling. However, as a changeset can
>>> have potential children which would dissallow amending, we have to recreate the
>>> commit and therefore all hashes after a first stop are changing.
>> What happens if I do 'stop' but don't make changes? Does the user get
>> to retain the original, non-fussed-with hash?
>> (I'm not 100% sure it's a showstopper if the answer is "no", but I'd
>> really like the answer to be "yes".)
> The answer here is "no". When we are recreating the node, we are getting
> a new hash. We would need to be able to compare afterwards if the new
> node and the original node "match", consdering they have different
> hashes. As far as I can tell we don't have any way to do that at the
> moment, so I opted that we always recreate the node if you use stop and
> have obsolence markers disabled.

Could you compare the manifest node? Would that always be the same?

> - David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20140909/8a0ab4d9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20140909/8a0ab4d9/attachment.pgp>

More information about the Mercurial-devel mailing list