Re: Exposing the states of sequencer, etc.

From: Phil Hord <phil.hord@gmail.com>
Date: Apr 20, 2019, 06:52 UTC
Message-ID: <CABURp0rnca4+nxipNGSU-h9miAmAvhzxO9U-T-sgPCyHeu+Xjw@mail.gmail.com>
In-Reply-To: <20190419194649.GB28277@sigill.intra.peff.net>

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@peff.net> wrote:

Show 35 quoted lines

>
> 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