{"thread":{"id":"50953","subject":"Exposing the states of sequencer, etc.","startedAt":"2019-04-19T18:26:05Z","lastAt":"2019-04-20T06:52:40Z","messageCount":3,"participants":["Phil Hord","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"374143","messageId":"CABURp0p6RmwjW4BN4qPv5iBKC_kzZFGyKJxuWw=+pEpjZGtV_A@mail.gmail.com","threadId":"50953","inReplyTo":null,"subject":"Exposing the states of sequencer, etc.","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2019-04-19T17:57:33Z","receivedAt":"2019-04-19T18:26:05Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"\"Junio C Hamano via vger.kernel.org\" writes:\n\n> > When cherry-picking or reverting a sequence of commits and if the final\n> > pick/revert has conflicts and the user uses `git commit` to commit the\n> > conflict resolution and does not run `git cherry-pick --continue` then\n> > the sequencer state is left behind. This can cause problems later.\n> > ...\n> I've certainly seen this myself.  Do you use command line prompt\n> support to remind you of the operation in progress?  I do, and I\n> have a suspicion that it did not help me in this situation by\n> ceasing to tell me that I have leftover state files after a manual\n> commit of the final step that conflicted and gave control back to\n> me.\n\nIs there some place today that we explain the many rules Git uses to\ndetermine the operations in progress?  I once had a patch to do this\nin code, but I think I let it die in committee.  It was something\nlike:\n\n     $ git status --show-progress-state\n     cherry-pick, conflicts, untracked\n\nIt would be helpful first to have an API for this, of course, though I\nthink that's where I got mired before.\n\nI'm willing to take it on again, if there's not already some alternative.\n"},{"id":"374159","messageId":"20190419194649.GB28277@sigill.intra.peff.net","threadId":"50953","inReplyTo":"CABURp0p6RmwjW4BN4qPv5iBKC_kzZFGyKJxuWw=+pEpjZGtV_A@mail.gmail.com","subject":"Re: Exposing the states of sequencer, etc.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-04-19T19:46:49Z","receivedAt":"2019-04-19T19:46:53Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 19, 2019 at 10:57:33AM -0700, Phil Hord wrote:\n\n> \"Junio C Hamano via vger.kernel.org\" writes:\n> \n> > > When cherry-picking or reverting a sequence of commits and if the final\n> > > pick/revert has conflicts and the user uses `git commit` to commit the\n> > > conflict resolution and does not run `git cherry-pick --continue` then\n> > > the sequencer state is left behind. This can cause problems later.\n> > > ...\n> > I've certainly seen this myself.  Do you use command line prompt\n> > support to remind you of the operation in progress?  I do, and I\n> > have a suspicion that it did not help me in this situation by\n> > ceasing to tell me that I have leftover state files after a manual\n> > commit of the final step that conflicted and gave control back to\n> > me.\n> \n> Is there some place today that we explain the many rules Git uses to\n> determine the operations in progress?  I once had a patch to do this\n> in code, but I think I let it die in committee.  It was something\n> like:\n> \n>      $ git status --show-progress-state\n>      cherry-pick, conflicts, untracked\n> \n> It would be helpful first to have an API for this, of course, though I\n> think that's where I got mired before.\n> \n> I'm willing to take it on again, if there's not already some alternative.\n\nGrep for get_state and print_state in wt-status.c. I think we only do so\nfor the \"long\" status output, but it should be possible to define a\nmachine-readable version for the porcelain output.\n\n-Peff\n"},{"id":"374172","messageId":"CABURp0rnca4+nxipNGSU-h9miAmAvhzxO9U-T-sgPCyHeu+Xjw@mail.gmail.com","threadId":"50953","inReplyTo":"20190419194649.GB28277@sigill.intra.peff.net","subject":"Re: Exposing the states of sequencer, etc.","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2019-04-20T06:52:25Z","receivedAt":"2019-04-20T06:52:40Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"Ah, yes.  Thanks for the reminder, Peff.  Found my original patch:\n\nhttp://git.661346.n2.nabble.com/PATCHv2-git-status-show-short-sequencer-state-tc7569767.html#a7570756\n\nI seem to recall that my next iteration of it ran into many conflicts\nin wt_status.c, and that file seemed like it might be heading in this\nAPI direction anyway, so I put it on a shelf.  I guess I'm just\nsurprised the state checking is still so manual.  I'll explore more.\n\nOn Fri, Apr 19, 2019 at 12:46 PM Jeff King <peff@peff.net> wrote:\n>\n> On Fri, Apr 19, 2019 at 10:57:33AM -0700, Phil Hord wrote:\n>\n> > \"Junio C Hamano via vger.kernel.org\" writes:\n> >\n> > > > When cherry-picking or reverting a sequence of commits and if the final\n> > > > pick/revert has conflicts and the user uses `git commit` to commit the\n> > > > conflict resolution and does not run `git cherry-pick --continue` then\n> > > > the sequencer state is left behind. This can cause problems later.\n> > > > ...\n> > > I've certainly seen this myself.  Do you use command line prompt\n> > > support to remind you of the operation in progress?  I do, and I\n> > > have a suspicion that it did not help me in this situation by\n> > > ceasing to tell me that I have leftover state files after a manual\n> > > commit of the final step that conflicted and gave control back to\n> > > me.\n> >\n> > Is there some place today that we explain the many rules Git uses to\n> > determine the operations in progress?  I once had a patch to do this\n> > in code, but I think I let it die in committee.  It was something\n> > like:\n> >\n> >      $ git status --show-progress-state\n> >      cherry-pick, conflicts, untracked\n> >\n> > It would be helpful first to have an API for this, of course, though I\n> > think that's where I got mired before.\n> >\n> > I'm willing to take it on again, if there's not already some alternative.\n>\n> Grep for get_state and print_state in wt-status.c. I think we only do so\n> for the \"long\" status output, but it should be possible to define a\n> machine-readable version for the porcelain output.\n>\n> -Peff\n"}]}