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
