Exposing the states of sequencer, etc.

Exposing the states of sequencer, etc.

[Phil Hord]

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

Re: Exposing the states of sequencer, etc.

[Jeff King]

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

Re: Exposing the states of sequencer, etc.

[Phil Hord]

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