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

From: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Date: Sep 3, 2023, 20:18 UTC
Message-ID: <ZPTqEIvW3zJ4eafT@ugly>
In-Reply-To: <fdf80c36-0e28-44f3-9cef-85d38d2d48f1@gmail.com>

On Sun, Sep 03, 2023 at 08:48:14PM +0100, Phillip Wood wrote:

Show 10 quoted lines

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

Show 6 quoted lines

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