Continuing operations after resolving conflicts?

[justinfenn]

I have a patch series that looks like this:

$ stg series
+ a1
+ a2
+ a3
+ b1
+ a4
+ b2
+ a5
> a6

I want to move b1 and b2 to the top of the stack, so I ran stg float b1 b2. This gave me a conflict at a5 which is not unexpected. I resolved the conflict and ran stg add <file> and then stg refresh as the conflicts section in the tutorial says to do. The patch series now looks like this:

$ stg series
+ a1
+ a2
+ a3
+ a4
> a5
- b1
- b2
- a6

It seems the whole float operation just stops here. Is there anything similar to git rebase --continue that will resume the original operation? If I do stg push to apply the the top 3 patches and run the float command again, then eventually the series will look the way I want it to. I'm just wondering if I'm missing a shortcut or if this is how it's intended to work.

[jpgrayson]

You are not missing anything. StGit does not have the concept of stateful resumption of its stack manipulation commands like git does with git rebase --continue.

Should it though? I don't know, maybe.

This would seem to affect goto, float, push (when multiple patches are provided), sink, pick (when picking multiple patches), delete, pull, and rebase commands. Would there be a general purpose command to resume whichever of those was interrupted by merge conflict resolution? Or would each command have it's own --continue flag? And how/where would StGit retain the state needed to resume?

I've personally always been wary of git's resumable commands, so I've not had a desire to have a similar mode of operation in StGit.

I think such a feature would need a champion other than myself.

[justinfenn]

That makes sense. It does seem like a lot of additional complexity. Thanks for the response!

[lkraav]

Well, one of the annoying cases is when you do something like stg push -n 10 and run into a conflict.

After resolve and refresh, now you need to do another eyeball run to understand how many patches left to push. Here, I'd certainy appreciate a stg rebase --continue option.

[jpgrayson]

When using stg push -n 10, how do you come up with the -n 10? I used to run commands like that by looking at stg series identifying the patch I wanted to get to, and then using stg push -n 10 instead of stg goto patch-name-thats-too-long-to-type.

I added a bunch of features for working with patches using absolute and relative indexes to ease some of these workflows.

For example, I rarely run plain stg series anymore. Instead, I have an alias stg kk which expands to stg series -rId (--reverse --indices --description). This shows the series in reversed, or "stack" order where the top patch is visually at the top. It also shows absolute patch indices.

Using an absolute patch index, stg push -n 10 could become, for example, stg goto 12.

And if there were any merge conflicts to resolve, the same stg goto 12 could be repeated after each merge conflict resolution.

This is how I navigate the stack these days.

[lkraav]

All of the above sounds good, I'll give those a shot.

[lkraav]

stg goto is pretty good, but still, after stg rebase runs into a conflict, you need to note or remind yourself of the top patch name to goto after resolving conflict.