[PATCH 1 of 2] histedit: add stop verb

[Durham Goode]

On 9/9/14, 5:34 PM, "David Soria Parra" <davidsp at fb.com> wrote:

>
>
>Am 9/9/14, 10:32 AM, schrieb Augie Fackler:
>> 
>> On Sep 9, 2014, at 12:54 PM, David Soria Parra <davidsp at fb.com> wrote:
>> 
>>>
>>>
>>> Am 9/9/14, 9:35 AM, schrieb Augie Fackler:
>>>>
>>>> On Sep 9, 2014, at 12:34 PM, David Soria Parra <davidsp at fb.com
>>>> <mailto: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 <mailto: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?
>>>
>>> Yes. But this assumes that the user didn't change just the commit
>>> message or author.
>> 
>> 
>> Hm.
>> 
>> Could we just only offer 'stop' if the user has obsolete enabled? Would 
>>that be sufficient for Facebook today, and not put weird edge cases into 
>>the behavior of histedit?
>
>I don't think that will be sufficient. Obsolence markers have too much
>of a perf impact these days to be enabled.
>

I think stop must always change the hash, because if the user records that 
hash (ex: by running a code review tool) it needs to remain valid, even if 
the user didn’t change the commit.

I also think the feature is useful enough to put in core, even with the 
weirdisms.  Alternatively we could pop the entire histedit stack off 
before doing anything, then apply the commits fresh, one by one.  Thus 
allowing users to amend a commit before the children are applied.