On Tue, 07 Jul 2026 at 14:02:41 +0200, Oswald Buddenhagen wrote:
> grepping the history for "factor" and "extract" (and "\<move", though that
> yields a lot of false positives), you'll find that most refactorings are
> directly followed by other changes that build on them.
For comparison, would you consider my initial macOS keychain patch
(d35919d8831c) to be a valid refactor due to the next two patches
building on it, or would it be leaning on being churn? I ask to better
understand what you consider as useful or needless wrt refactoring.
> it's certainly tempting to extract the authentication logic, as that's 500
> lines of seemingly well-isolated code.
> you can give it another shot, but this time don't try to solve several
> problems at once,
Sure thing. Can this involve an imap_auth.c file or must all logic stay
within drv_imap.c?
Also now that I've learnt the GSASL API I'll try to tag along a second
patch adding that too.
> speaking of splitting off more parts, see wip/server-refactor. i tentatively
> gave up on that one, because the protocol is just extremely messy
I actually have been eyeing that branch for a bit. I'm drawn to giving
it a shot at completion, but I'm inexperienced with regard to working on
branches that have fallen well behind from their base branch. As in I'm
unsure whether to, say, first rebase the branch on a newer commit, or
continue work on its current out-of-date base, or even just start anew
on master/master-next.
Take care,
Seth McDonald.
--
E9D1 26A5 F0D4 9DF7 792B C2E2 B4BF 4530 D39B 2D51
_______________________________________________
isync-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/isync-devel
