{"thread":{"id":"32093","subject":"Candidates for sequencer?","startedAt":"2012-11-12T21:46:51Z","lastAt":"2012-11-12T22:16:13Z","messageCount":2,"participants":["Ramkumar Ramachandra","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"203006","messageId":"CALkWK0n0tTZ3EgzeesOr2B1LjeEUjTnWQh5dDfW28jA1ia0-gA@mail.gmail.com","threadId":"32093","inReplyTo":null,"subject":"Candidates for sequencer?","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2012-11-12T21:46:51Z","receivedAt":"2012-11-12T21:46:51Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nI'd like to get more commands to call into sequencer.c, so that we can\n(finally) implement a sensible `git continue` and `git abort`.\nCurrently, am and rebase come to mind, but they are shell scripts and\nI don't see how we can make them call into sequencer.c.  Is there any\nway to make sequencer.c more useful?  Should we implement a `git\ncontinue` and `git reset` anyway, lifting code from 83c750ac to check\nthe tree state?\n\nRam\n"},{"id":"203008","messageId":"20121112221613.GC10531@sigill.intra.peff.net","threadId":"32093","inReplyTo":"CALkWK0n0tTZ3EgzeesOr2B1LjeEUjTnWQh5dDfW28jA1ia0-gA@mail.gmail.com","subject":"Re: Candidates for sequencer?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-11-12T22:16:13Z","receivedAt":"2012-11-12T22:16:13Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 13, 2012 at 03:16:51AM +0530, Ramkumar Ramachandra wrote:\n\n> I'd like to get more commands to call into sequencer.c, so that we can\n> (finally) implement a sensible `git continue` and `git abort`.\n> Currently, am and rebase come to mind, but they are shell scripts and\n> I don't see how we can make them call into sequencer.c.  Is there any\n> way to make sequencer.c more useful?  Should we implement a `git\n> continue` and `git reset` anyway, lifting code from 83c750ac to check\n> the tree state?\n\nI'd love it if ther was a mechanism for interruptible commands to notify\nthe rest of git that they are in progress. This would not only make\ncross-language commands like \"rebase\" and \"am\" work easily, but it would\nmean that we can automatically support third-party commands that we\ndon't even know about.\n\nI am already doing something like this for some personal scripts which\ndo sequences of merges and rebases, and my \"git continue\" looks like:\n\n  if test -f \"$GIT_DIR/continue\"; then\n    eval \"$(cat \"$GIT_DIR/continue\")\"\n  elif test -d \"$GIT_DIR/rebase-merge\"; then\n    git rebase --continue\n  elif test -d \"$GIT_DIR/rebase-apply\"; then\n    if test -f \"$GIT_DIR/rebase-apply/applying\"; then\n      git am --continue\n    else\n      git rebase --continue\n    fi\n  fi\n  [... etc ...]\n\nIt works pretty well in practice, but I'd have a few suggestions on top:\n\n  1. Even if \"am\" and \"rebase\" learn to use $GIT_DIR/continue, we should\n     probably continue to support the fallback state-examination in case\n     people use mixed versions of git. And clearly the code should be\n     shared with what's in wt-status.c.\n\n  2. The \"continue\" file should probably be called \"in-progress\", and\n     should have more structured data, like the name of the operation.\n\n  3. The list of operations in progress needs to be a stack. If I am\n     rebasing and start a cherry pick, what would \"git continue\" do? It\n     probably makes sense to continue the most recently started\n     operation first.\n\n  4. Rebase already detects an in-progress rebase. It should probably\n     also detect an \"am\" or \"cherry-pick\" in progress. But it's not\n     commutative; you should be able to start a \"cherry-pick\" in the\n     middle of a \"rebase\". This is really independent of the storage\n     format (we could do it right now if the state logic from wt-status\n     is made available in a machine-readable format).\n\n     We _might_ want to put information in the in-progress file that\n     helps programs reach that decision. I'm not sure of a sane way of\n     doing it, though. You could say \"don't rebase while I'm in\n     progress\", but that depends on the writer knowing the universe of\n     all programs that might be run. It might be possible to come up\n     with some taxonomy of operations like \"a history rewriting\n     operation is in progress\" which would cause other history rewriting\n     operations to choose not to start. But coming up with the right set\n     of attributes might be impossible.\n\n-Peff\n"}]}