Subject: Re: [PATCH] sequencer: update abort safety file more sparingly

From: Oswald Buddenhagen <[email-masked]>
Date: Sun, 3 Sep 2023 22:18:24 +0200

On Sun, Sep 03, 2023 at 08:48:14PM +0100, Phillip Wood wrote:
>On 03/09/2023 20:25, Oswald Buddenhagen wrote:
>> On Sun, Sep 03, 2023 at 07:40:00PM +0100, Phillip Wood wrote:
>>> it only matters for "cherry-pick --skip"
>>>
>> that doesn't seem right. a --skip is just a --continue with a prior 
>> reset, more or less.
>
>sequencer_skip() calls rollback_is_safe() which checks the abort safety 
>file.
>
that's weird. can you think of a good reason for doing that?

>> i'll try to find a better "choke point".
>
>I think that is probably tricky,
>
yeah

>I'm not really clear what the aim/purpose of this refactoring is.
>
to make my head not explode.
more specifically, to get it out of the way of the rebase path, which is 
what i'm actually concerned with.

generally, i think this whole ad-hoc state management is a nightmare, 
and i'd be surprised if there weren't some more loose ends.
i think i'd aim for an object-oriented-ish design with an encapsulated 
state, lazy loading getters, lazy setters, and a commit entry point (or 
maybe several partial ones). no idea how that would play out.

>> if you did a fresh commit before or after the single pick, you'd lose 
>> it.
>
>Oh, I can see that you'd lose a commit made before a single pick but I 
>don't see how you'd lose a commit made after it.
>
right. thinko. it's a bit late here. ^^

regards