Ah, yes. Thanks for the reminder, Peff. Found my original patch: http://git.661346.n2.nabble.com/PATCHv2-git-status-show-short-sequencer-state-tc7569767.html#a7570756 I seem to recall that my next iteration of it ran into many conflicts in wt_status.c, and that file seemed like it might be heading in this API direction anyway, so I put it on a shelf. I guess I'm just surprised the state checking is still so manual. I'll explore more. On Fri, Apr 19, 2019 at 12:46 PM Jeff King <peff@xxxxxxxx> wrote: > > On Fri, Apr 19, 2019 at 10:57:33AM -0700, Phil Hord wrote: > > > "Junio C Hamano via vger.kernel.org" writes: > > > > > > When cherry-picking or reverting a sequence of commits and if the final > > > > pick/revert has conflicts and the user uses `git commit` to commit the > > > > conflict resolution and does not run `git cherry-pick --continue` then > > > > the sequencer state is left behind. This can cause problems later. > > > > ... > > > I've certainly seen this myself. Do you use command line prompt > > > support to remind you of the operation in progress? I do, and I > > > have a suspicion that it did not help me in this situation by > > > ceasing to tell me that I have leftover state files after a manual > > > commit of the final step that conflicted and gave control back to > > > me. > > > > Is there some place today that we explain the many rules Git uses to > > determine the operations in progress? I once had a patch to do this > > in code, but I think I let it die in committee. It was something > > like: > > > > $ git status --show-progress-state > > cherry-pick, conflicts, untracked > > > > It would be helpful first to have an API for this, of course, though I > > think that's where I got mired before. > > > > I'm willing to take it on again, if there's not already some alternative. > > Grep for get_state and print_state in wt-status.c. I think we only do so > for the "long" status output, but it should be possible to define a > machine-readable version for the porcelain output. > > -Peff
