[PATCH 1 of 2] histedit: add stop verb

[Augie Fackler]

On Tue, Sep 9, 2014 at 3:07 PM, David Soria Parra <davidsp at fb.com> wrote:
>
>
> Am 9/9/14, 11:02 AM, schrieb Durham Goode:
>>
>> On 9/9/14, 10:54 AM, Augie Fackler wrote:
>>> On Sep 9, 2014, at 1:52 PM, Durham Goode <durham at fb.com> wrote:
>>>
>>>> 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.
>>> Hm, interesting point. That probably applies to 'exec' as well?
>>>
>>> The reason I'm dithering about this so much is that we've already got
>>> some open bugs (that I'd like to fix) that histedit causes hashes to
>>> change even when you make no edits, so it's kind of a bummer to make
>>> some more of that behavior. I'm starting to be convinced we can't
>>> avoid it though, which is a little tragic.
>> How crazy is my idea to strip everything first?  That solves our hash
>> problem and we're going to have to do the strip eventually anyway.  It
>> might remove the ability for someone to diff against the original
>> version, but that's a capability they don't actually have today, so we
>> wouldn't be removing functionality.
>
> I am not too happy about that. It would mean that pick, etc behaviour
> changes significantly for current users. The stop behaviour is far from
> ideal but it does not tinker with the current behaviours of pick & co.

marmoute had a good idea on irc: see if we can allow amending changes
during histedit, and then have the histedit machinery clean up after
itself when done. dsop said he'd investigate, so I'm going to unflag
this series for now.

>
>>>> 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.
>>