(single comment, don't treat it as full review)

I suggest calling git format-patch with --base=<commit>. This will add base-commit: <commit> to the end of first created patch, which in turn should make it easier to find a point where it applies clearly, even after some time. There is also --base=auto, but I find it unreliable for some cases. Full commit digest would also help reviewer (or maybe even CI in the future) to test whether patches are created on top of expected base commit, and not some locally modified content.

@krystian-hebel As you can see I experimented with that: #4

We do not yet understand how patches are managed using tools like Guilt. I'm pretty sure my lack of understanding of the tool contributes to the lack of convincing documentation and a comprehensive process, so the whole approach is at the pre-PoC stage. We can also consult professionals who have used the tool for a very long time, like Andrew. I'm pretty sure they use tools for a reason.

At first glance, I see a lot of benefits of using guilt, but I didn't produce release yet so maybe my observations are not yet good enough evidence of guilt value. For example, as explained in README.md (How to handle bug in patches ?), the way of updating patches seems to be very convenient.

The second thing I really recommend is playing with guilt since the experience is much different between reading about it vs using it; when I read about guilt, I was very skeptical, but while using it, I see more and more value when juggling with patches.