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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux