Auto-`pop` a chain of patches to avoid merge conflicts

[bonki]

Assume we have A---B---C1---C2---D---E where {A,B,D,E} are completely unrelated to one another and C2 builds on top of C1. While working on E we understand that C1 introduced a bug which requires extensive debugging so we would like to pop C1 and continue working on E. Unfortunately, solely popping C1 would of course lead to a merge conflict when stg tries to re-apply C2. Fortunately, C2 isn't relevant for us either while continuing our work on E so we can e.g. undo and pop both patches in a batch.

Ideally, I would like to be able to do something along the lines of

$ stg pop --follow foo  # C1

which would pop all required (consecutive?) patches starting at foo so that the result would be a conflict-free state, if possible. In the scenario above this would leave us with C1..C2 popped, in the worst case scenario this would pop foo..top, which might also be fine.

This avoids either (i) the cognitive overhead of having to know which patches are related and require to be unapplied together or (ii) having to go through an iterative dance of commands to avoid/resolve merge conflicts which we aren't really interested in.

The worst case is that too many patches get popped (i.e. an immediate patch which is required for us to continue working), but at least it would only take a single command to know that as well as tell us which range of patches exactly one would need to have a closer look at, instead of arriving at this point iteratively.

[jpgrayson]

If I'm understanding the request, this feature would associate patches based on whether and where merge conflicts emerge. I think that's an interesting idea; I hadn't considered it before.

That said, there are other non-lexical dependencies that can and do exist between patches. E.g. patch C2 can depend on C1 because C1 introduces a new symbol in x.source that is added to y.source in C2.

Point being, if StGit had a notion of patch dependencies, I think I would prefer a more generalized mechanism that allowed the user to specify dependencies. Though I could imagine supplementing manually specified patch dependencies with an automated mechanism to find lexical dependencies as suggested here.

See also this discussion on patch dependencies.