[PATCH 1 of 2] histedit: add stop verb
David Soria Parra
davidsp at fb.com
Tue Sep 9 14:07:36 CDT 2014
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
>>> 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.
>>> 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.
More information about the Mercurial-devel