{"thread":{"id":"38296","subject":"Additional plumbing commands","startedAt":"2015-01-06T16:05:42Z","lastAt":"2015-01-07T16:31:04Z","messageCount":4,"participants":["Charles Rudolph","Christian Couder","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"254342","messageId":"CA+SVznFFPED+ms=4abNpvNQx-nt6imDMJtYKuNBTTLzCJ547Vw@mail.gmail.com","threadId":"38296","inReplyTo":null,"subject":"Additional plumbing commands","fromName":"Charles Rudolph","fromEmail":"charles.w.rudolph@gmail.com","sentAt":"2015-01-06T16:05:42Z","receivedAt":"2015-01-06T16:05:42Z","isPatch":false,"sender":{"key":"charles.w.rudolph@gmail.com","avatar":null},"body":"I am writing some higher level git commands for\nhttps://github.com/Originate/git-town and would like some additional\nplumbing commands that can tell me\n\n1. is there a merge in progress?\n2. is there a rebase in progress?\n3. is there a cherry-pick in progress?\n4. are there unmerged paths?\n\nCurrently the only way I know how to do this is with \"git status\" and\nlooking for specific text.\n\nThanks for any and all comments.\n\n~Charlie\n"},{"id":"254347","messageId":"CAP8UFD1OZ1QjHRyNGVs0Vm52=Ue-ta1gBzNxLpX25NSCbtu9EQ@mail.gmail.com","threadId":"38296","inReplyTo":"CA+SVznFFPED+ms=4abNpvNQx-nt6imDMJtYKuNBTTLzCJ547Vw@mail.gmail.com","subject":"Re: Additional plumbing commands","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2015-01-06T17:37:34Z","receivedAt":"2015-01-06T17:37:34Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tue, Jan 6, 2015 at 5:05 PM, Charles Rudolph\n<charles.w.rudolph@gmail.com> wrote:\n> I am writing some higher level git commands for\n> https://github.com/Originate/git-town and would like some additional\n> plumbing commands that can tell me\n>\n> 1. is there a merge in progress?\n> 2. is there a rebase in progress?\n> 3. is there a cherry-pick in progress?\n> 4. are there unmerged paths?\n>\n> Currently the only way I know how to do this is with \"git status\" and\n> looking for specific text.\n\nYou may have a look at how \"contrib/completion/git-prompt.sh\" does it.\nIt has stuff like:\n\n        if [ -d \"$g/rebase-merge\" ]; then\n                __git_eread \"$g/rebase-merge/head-name\" b\n                __git_eread \"$g/rebase-merge/msgnum\" step\n                __git_eread \"$g/rebase-merge/end\" total\n                if [ -f \"$g/rebase-merge/interactive\" ]; then\n                        r=\"|REBASE-i\"\n                else\n                        r=\"|REBASE-m\"\n                fi\n...\n\nCheers,\nChristian.\n"},{"id":"254397","messageId":"20150107080408.GA1301@peff.net","threadId":"38296","inReplyTo":"CAP8UFD1OZ1QjHRyNGVs0Vm52=Ue-ta1gBzNxLpX25NSCbtu9EQ@mail.gmail.com","subject":"Re: Additional plumbing commands","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-01-07T08:04:09Z","receivedAt":"2015-01-07T08:04:09Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 06, 2015 at 06:37:34PM +0100, Christian Couder wrote:\n\n> On Tue, Jan 6, 2015 at 5:05 PM, Charles Rudolph\n> <charles.w.rudolph@gmail.com> wrote:\n> > I am writing some higher level git commands for\n> > https://github.com/Originate/git-town and would like some additional\n> > plumbing commands that can tell me\n> >\n> > 1. is there a merge in progress?\n> > 2. is there a rebase in progress?\n> > 3. is there a cherry-pick in progress?\n> > 4. are there unmerged paths?\n> >\n> > Currently the only way I know how to do this is with \"git status\" and\n> > looking for specific text.\n> \n> You may have a look at how \"contrib/completion/git-prompt.sh\" does it.\n> [...]\n\nThe prompt code is rather long and knows a lot about the internal state\nof $GIT_DIR. I do not think it would be a bad thing for git-status to\nexpose a machine-readable version of the state it discovers, and then at\nleast we can keep the logic in one place.\n\nCharles, if you are interested in adding that, the wt_status_state code\nin wt-status.c is the right place to start looking.\n\nThough I think in many cases that discovering which state we are in is\nonly half the story that a caller wants. Knowing what each state _means_\nand what operations are meaningful to perform is much trickier (e.g., if\nwe are in a rebase, you probably do not want to start a new rebase. But\nis it wrong to cherry-pick?).\n\nIt would be nice if we could find a way to generalize in-progress\noperations and what they mean for starting new operations, but that is\na much harder problem (if it is even possible at all).\n\n-Peff\n"},{"id":"254404","messageId":"xmqqa91ulfhz.fsf@gitster.dls.corp.google.com","threadId":"38296","inReplyTo":"20150107080408.GA1301@peff.net","subject":"Re: Additional plumbing commands","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-01-07T16:31:04Z","receivedAt":"2015-01-07T16:31:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> ... Knowing what each state _means_\n> and what operations are meaningful to perform is much trickier (e.g., if\n> we are in a rebase, you probably do not want to start a new rebase. But\n> is it wrong to cherry-pick?).\n>\n> It would be nice if we could find a way to generalize in-progress\n> operations and what they mean for starting new operations, but that is\n> a much harder problem (if it is even possible at all).\n\nVery good points. Thinking aloud, to see if we can start from a few\nrules of thumb.\n\nYou can be \"in the middle\" for two largely different reasons.\n\nOne is that the command inherently wants to give control back to\nyou.  Think of a case where you said \"exec false\" in the \"rebase -i\"\ninsn sheet, or \"bisect\" checked out a version for you to try.\n\nThe other is that the command wanted to continue in the ideal world,\nbut couldn't and stopped asking for your help.  Think of a case\nwhere \"am\" stopped due to corrupt patch, \"cherry-pick A..B\" or\n\"revert\" stopped due to conflicts.\n\nIn the former case, depending on the nature of the command, what are\nsensible things you can do are very different (during \"bisect\" you\nwould typically not want to do anything that causes a commit\ncreated.  During \"rebase -i\" you may want to run any command that\ncreates a commit, to insert a new one into the series).  But a good\nrule of thumb would be \"If I should be able to edit the working tree\nfile, I should also be able to do \"cherry-pick --no-commit\", \"merge\n--no-commit\", \"apply\", etc.\" \"If I should be able to manually\ncommit, I should also be able to \"cherry-pick\", \"merge\", etc.\n\nIn the latter, the _only_ reason you are given control back is to\nhelp the interrupted operation.  So \"cherry-pick --no-commit\" or\n\"apply\" in lieu of editing files manually in order to fix conflicts\nshould be allowed, but a random \"git merge\" (without --no-commit)\nwould not be.\n\nSo after thinking aloud for a while, I very much agree with you that\nyou cannot say \"X is allowed but not Y\" in many situations.\n\nOne thing we can say for sure is that in a middle of a multi-step\noperation (e.g. rebase, range pick) is stopped for either one of the\ntwo reasons, you cannot do another multi-step operation.  This is\nnot fundamental but a consequence of how the sequencing machinery is\nimplemented.  But other than that, it really is case-by-case and not\neven command-by-command.\n"}]}