Same workflow here, and it's become a breeze with autofix, rebase --update-refs, and a small command to push the whole stack.
I'm using magit, so I directly see what could not be matched and remains staged.
Yes, I empirically found the hunk-based approach of git autofixup to work more reliably. I use it via magit.
Paired with rebase --update-refs, it's particularly helpful to automatically fixup stacked branches.
You don't have to restrict yourself to betterC to use manual memory management. BetterC is mainly targetted at embedded programming and to port components of existing C applications. Malloc vs. GC vs. stdx-allocator is a separate topic, though betterC doesn't link with the GC by default.
You loose builtin arrays and hashes and need to use a container library instead. Same goes for newing aggegates which can be replaced with smart pointers.
Escaping closures (delegates) no longer works, but you can explicitly capture context in a struct.
Those choices for builtin language features date back to the early inspiration from Java, but are increasingly being replaced with library implementations.
We've added escape checking to the type system last year, and are currently working on safe aliasing (preventing use-after-free).
So yes, atm. when opting for @nogc you're somewhat at the frontier, and it's mostly a choice if you have time, hard requirements, or am very practised.
Avoiding most (but not all) GC allocations is already widely adopted in D's community though.
