{"thread":{"id":"27602","subject":"[RFC PATCH v2] revert: Implement --abort processing","startedAt":"2011-06-11T06:36:26Z","lastAt":"2011-06-13T20:28:06Z","messageCount":8,"participants":["Ramkumar Ramachandra","Jonathan Nieder"],"isPatch":true,"patchVersion":2,"patchTotal":null},"messages":[{"id":"169873","messageId":"1307774186-14207-1-git-send-email-artagnon@gmail.com","threadId":"27602","inReplyTo":null,"subject":"[RFC PATCH v2] revert: Implement --abort processing","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2011-06-11T06:36:26Z","receivedAt":"2011-06-11T06:36:26Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"To abort, simply reset the HEAD to the location specified by the\nHEAD_FILE written earlier, without touching the worktree or index.  It\nis upto the user to execute \"rerere clear\", \"reset --hard\", and \"reset\n--merge\" as approprite.\n\nHelped-by: Jonathan Nieder <jrnieder@gmail.com>\nHelped-by: Junio C Hamano <gitster@pobox.com>\nHelped-by: Jeff King <peff@peff.net>\nSigned-off-by: Ramkumar Ramachandra <artagnon@gmail.com>\n---\n I've persisted the TODO early, and made it complain when an existing\n cherry-pick/ revert is in progress.  Further, as Junio suggested,\n I've made no attempt to touch the index or the worktree during the\n --abort operation: I simply update HEAD and leave the user to do the\n rest.  Should we print some hints about this?\n\n However, by making it complain everytime a cherry-pick/ revert is in\n progress, I've essentially broken the entire testsuite -- everytime a\n test or even a script (see git-rebase.sh) calls cherry-pick or\n revert, I must call '--abort' to clean up afterwards.  Fixing this\n will require me to touch many seemingly unrelated files.\n\n Also, note that I'm depending on the \"libify reset\" patch I posted a\n few minutes ago to print_new_head_line exactly the way reset does.\n\n In other news, I've started writing '--continue' and '--skip'\n operations, but the limiting factor is the instruction sheet's\n format: I'm still wondering if there's any way to avoid being\n verbose/ ugly and flexible (by allowing command-line options for each\n instruction) at the same time.  Will post RFC patches asking more\n directed questions soon.\n\n Thanks.\n\n builtin/revert.c                |   85 +++++++++++++++++++++++++++++++++++---\n t/t3510-cherry-pick-sequence.sh |   16 +++++++\n 2 files changed, 94 insertions(+), 7 deletions(-)\n\ndiff --git a/builtin/revert.c b/builtin/revert.c\nindex e1a05a3..efcc01f 100644\n--- a/builtin/revert.c\n+++ b/builtin/revert.c\n@@ -14,6 +14,7 @@\n #include \"merge-recursive.h\"\n #include \"refs.h\"\n #include \"dir.h\"\n+#include \"reset.h\"\n \n /*\n  * This implements the builtins revert and cherry-pick.\n@@ -208,8 +209,6 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts)\n \t\t\t\tNULL);\n \n \t/* Remove these when the options are actually implemented */\n-\tif (opts->abort_oper)\n-\t\tdie(\"--abort is not implemented yet\");\n \tif (opts->skip_oper)\n \t\tdie(\"--skip is not implemented yet\");\n \tif (opts->continue_oper)\n@@ -719,6 +718,7 @@ static int pick_commits(struct replay_opts *opts)\n \tstruct commit *commit;\n \tunsigned char sha1[20];\n \tconst char *head;\n+\tint res;\n \n \tsetenv(GIT_REFLOG_ACTION, me, 0);\n \n@@ -730,11 +730,30 @@ static int pick_commits(struct replay_opts *opts)\n \tpersist_head(head);\n \tprepare_revs(&revs, opts);\n \n+\t/* Prepare todo_list and persist it early before picking */\n+\tstruct commit_list *todo_list = NULL;\n+\tstruct commit_list *cur = NULL;\n+\tstruct commit_list *new_item = NULL;\n+\n+\t/* Insert into todo_list in the same order */\n \twhile ((commit = get_revision(&revs))) {\n-\t\tint res = do_pick_commit(commit, opts);\n+\t\tnew_item = xmalloc(sizeof(struct commit_list));\n+\t\tnew_item->item = commit;\n+\t\tif (cur)\n+\t\t\tcur->next = new_item;\n+\t\telse\n+\t\t\ttodo_list = new_item;\n+\t\tcur = new_item;\n+\t}\n+\tcur->next = NULL;\n+\n+\tpersist_todo(todo_list, opts);\n+\n+\tfor (cur = todo_list; cur; cur = cur->next) {\n+\t\tres = do_pick_commit(cur->item, opts);\n \t\tif (res) {\n-\t\t\tcommit_list_insert(commit, &revs.commits);\n-\t\t\tpersist_todo(revs.commits, opts);\n+\t\t\tcommit_list_insert(cur->item, &todo_list);\n+\t\t\tpersist_todo(todo_list, opts);\n \t\t\treturn res;\n \t\t}\n \t}\n@@ -743,6 +762,58 @@ static int pick_commits(struct replay_opts *opts)\n \treturn cleanup_sequencer_dir();\n }\n \n+static int process_continuation(struct replay_opts *opts)\n+{\n+\tunsigned char sha1[20];\n+\tstruct commit *commit;\n+\tchar head_hex[40];\n+\tchar msg[1024];\n+\tint fd;\n+\n+\tif (opts->abort_oper) {\n+\t\t/* First, read the HEAD_FILE */\n+\t\tif (!file_exists(HEAD_FILE))\n+\t\t\tgoto error;\n+\t\tfd = open(HEAD_FILE, O_RDONLY, 0666);\n+\t\tif (fd < 0)\n+\t\t\treturn error(_(\"Could not open '%s' for reading: %s\"),\n+\t\t\t\tHEAD_FILE, strerror(errno));\n+\t\tif (read_in_full(fd, head_hex, 40) < 40 || get_sha1_hex(head_hex, sha1) < 0) {\n+\t\t\tclose(fd);\n+\t\t\treturn error(_(\"Corrupt '%s': %s\"), HEAD_FILE, strerror(errno));\n+\t\t}\n+\t\tclose(fd);\n+\n+\t\t/* Update the HEAD ref */\n+\t\tif (snprintf(msg, sizeof(msg), \"%s: updating HEAD\", me) >= sizeof(msg))\n+\t\t\twarning(_(\"Reflog action message too long: %.*s...\"), 50, msg);\n+\t\tif (update_ref(msg, \"HEAD\", sha1, NULL, 0, MSG_ON_ERR))\n+\t\t\treturn -1;\n+\t\tcommit = lookup_commit_reference(sha1);\n+\t\tprint_new_head_line(commit);\n+\n+\t\treturn cleanup_sequencer_dir();\n+\t}\n+\telse if (opts->skip_oper) {\n+\t\tif (!file_exists(TODO_FILE))\n+\t\t\tgoto error;\n+\t}\n+\telse if (opts->continue_oper) {\n+\t\tif (!file_exists(TODO_FILE))\n+\t\t\tgoto error;\n+\t}\n+\telse if (file_exists(HEAD_FILE)) {\n+\t\terror(_(\"A %s is already in progress\"), me);\n+\t\tadvise(_(\"Use %s --continue to continue the operation\"), me);\n+\t\tadvise(_(\"or %s --abort to start afresh\"), me);\n+\t\treturn -1;\n+\t}\n+\n+\treturn pick_commits(opts);\n+error:\n+\treturn error(_(\"No %s in progress\"), me);\n+}\n+\n int cmd_revert(int argc, const char **argv, const char *prefix)\n {\n \tint res;\n@@ -755,7 +826,7 @@ int cmd_revert(int argc, const char **argv, const char *prefix)\n \tgit_config(git_default_config, NULL);\n \tme = \"revert\";\n \tparse_args(argc, argv, &opts);\n-\tres = pick_commits(&opts);\n+\tres = process_continuation(&opts);\n \tif (res > 0)\n \t\t/* Exit status from conflict */\n \t\treturn res;\n@@ -775,7 +846,7 @@ int cmd_cherry_pick(int argc, const char **argv, const char *prefix)\n \tgit_config(git_default_config, NULL);\n \tme = \"cherry-pick\";\n \tparse_args(argc, argv, &opts);\n-\tres = pick_commits(&opts);\n+\tres = process_continuation(&opts);\n \tif (res > 0)\n \t\treturn res;\n \tif (res < 0)\ndiff --git a/t/t3510-cherry-pick-sequence.sh b/t/t3510-cherry-pick-sequence.sh\nindex a2e1888..c6ace35 100644\n--- a/t/t3510-cherry-pick-sequence.sh\n+++ b/t/t3510-cherry-pick-sequence.sh\n@@ -36,4 +36,20 @@ test_expect_success 'cherry-pick cleans up sequencer directory upon success' '\n \ttest_must_fail test -d .git/sequencer\n '\n \n+test_expect_success '--abort complains when no cherry-pick is in progress' '\n+\tpristine_detach initial &&\n+\ttest_must_fail git cherry-pick --abort >actual 2>&1 &&\n+\techo \"error: No cherry-pick in progress\" >expect &&\n+\ttest_i18ncmp expect actual\n+'\n+\n+test_expect_success '--abort restores HEAD after failed cherry-pick' '\n+\tpristine_detach initial &&\n+\thead=$(git rev-parse HEAD) &&\n+\ttest_must_fail git cherry-pick base..picked &&\n+\tgit cherry-pick --abort &&\n+\tnewhead=$(git rev-parse HEAD) &&\n+\ttest \"$head\" = \"$newhead\"\n+'\n+\n test_done\n-- \n1.7.4.1\n"},{"id":"169874","messageId":"20110611112213.GA25268@elie","threadId":"27602","inReplyTo":"1307774186-14207-1-git-send-email-artagnon@gmail.com","subject":"Re: [RFC PATCH v2] revert: Implement --abort processing","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-06-11T11:22:13Z","receivedAt":"2011-06-11T11:22:13Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n\n>  I've persisted the TODO early, and made it complain when an existing\n>  cherry-pick/ revert is in progress.  Further, as Junio suggested,\n>  I've made no attempt to touch the index or the worktree during the\n>  --abort operation: I simply update HEAD and leave the user to do the\n>  rest.\n\nIs that what Junio was suggesting?  I thought he was saying that\ncherry-pick shouldn't support an --abort option at all, since the\n\"right\" semantics are hard to find.\n\nI have sympathy for that point of view, too, but it's hard to\ncome up with the right choice.\n\nOn one hand: \"git am\" has an --abort option so you can say, \"Forget\nit; I'm going to go back to my mailer and make a better mailbox.\"\n\"git rebase\" has an --abort option to let you to walk away in a\ncomfortable state, instead of leaving the HEAD detached and halfway\nthrough replaying your work.  \"git bisect\" has a reset subcommand for\na similar reason.  All of the abort actions just mentioned take a\nsomewhat weird state (e.g., patch series partially applied, maybe with\nconflicts) and go back to something more familiar.  Which is useful,\nespecially for people just starting out.\n\nIt applies equally to cherry-pick: a user doing something crazy like\n\n\tgit cherry-pick HEAD..linux-next\n\nto incorporate all patches from linux-next on top of her local changes\nis creating a mess; there is appeal in having a way to say \"clear that\naway and take me back to something I knew\".\n\nOn the other hand: all three of the above \"abort\" actions can be a\npain in the neck in practice.  The worst case is when I forget about\nthe sequence in progress and do something else, and only later want to\nclear the state:\n\n http://thread.gmane.org/gmane.comp.version-control.git/164002/focus=164046\n\nThere are other cases, too, like when after partially rebasing I\ndecide this isn't a good direction for the original branch after all\nbut I want to end the rebase and develop HEAD as a new branch instead.\nThe --abort command is quite destructive and not very flexible.\n\nI guess if I were in your shoes, I'd be tempted to start by saving the\nold HEAD and making it visible as a pseudo-ref or something,\nadvertising that, and then observing people's behavior with the hope\nof using that knowledge to come up with good semantics for a command\nto cancel cherry-picks of commit ranges.  Do people use \"reset --hard\"\nor \"reset --merge\"?  Do they throw away all the commits cherry-picked\nor just a few?  Do they ever intend to abort like this even after\nveering from the standard sequence, like in Linus's example?  After\naborting a multiple cherry-pick, what does a person generally do next?\n\nThe documentation could say:\n\n\tTo wipe out everything and get back to where you started, use:\n\n\t\tgit reset --hard PRE_CHERRY_PICK_HEAD\n\nWhat if instead of --abort something else were simpler to think about?\nAs a random example, I can imagine a \"git sequencer --edit\" command\nthat would present the sequence in an editor and let me revise the\nplan --- would that do the trick?\n\n\t1\n\t2\n\t3\n\t4\n\t* YOU ARE HERE\n\t5\n\t6\n\t7\n\t8\n\n - Remove lines 5-8: removes sequencer state, leaves HEAD as is\n - Remove everything: rewinds to abort sequence\n - Add a line 2.5 between 2 and 3: rewind to 2, cherry-pick 2.5,\n   continue.\n\nAnd having said that, I personally start to see an --abort command as\ninteresting, because it is a specific case that could help flesh out a\nmore general behavior of rewinding some day years from now.\n\nWhich is to say: if you have a story about what --abort will be used\nfor, the life of others evaluating the thing becomes better and the\nupsides and downsides can be seen in perspective.  A story like \"am\nand rebase have --abort, so cherry-pick should have one, too\" is\nharder to think about.\n\nHope that helps.\n"},{"id":"169890","messageId":"BANLkTi=T0wCg1bKzmtQEQ-J-5ogqRZaqRg@mail.gmail.com","threadId":"27602","inReplyTo":"20110611112213.GA25268@elie","subject":"Re: [RFC PATCH v2] revert: Implement --abort processing","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2011-06-12T12:09:05Z","receivedAt":"2011-06-12T12:09:05Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi Jonathan,\n\nJonathan Nieder writes:\n> The documentation could say:\n>\n>        To wipe out everything and get back to where you started, use:\n>\n>                git reset --hard PRE_CHERRY_PICK_HEAD\n\nMy notion of --abort has changed: I simply want to remove the state\nfiles for the cherry-pick so that the user can execute more\ncherry-pick/ revert commands.  I didn't think a soft reset would be\nintrusive.  Hm, you're suggesting using a ref -- I was wondering what\nto do with CHERY_PICK_HEAD.  I'm not entirely convinced, but I'll wait\nfor the others to comment and think about this for some time.\n\n> What if instead of --abort something else were simpler to think about?\n> As a random example, I can imagine a \"git sequencer --edit\" command\n> that would present the sequence in an editor and let me revise the\n> plan --- would that do the trick?\n>\n>        1\n>        2\n>        3\n>        4\n>        * YOU ARE HERE\n>        5\n>        6\n>        7\n>        8\n>\n>  - Remove lines 5-8: removes sequencer state, leaves HEAD as is\n>  - Remove everything: rewinds to abort sequence\n>  - Add a line 2.5 between 2 and 3: rewind to 2, cherry-pick 2.5,\n>   continue.\n\nInteresting perspective.  I essentially have to keep two TODO files\nand run a diff until I find the first different line.  Then, I have to\nreset to that SHA-1 and replay the rest of the user-edited TODO.  Can\nbe complicated to get right, but it seems like quite an elegant\ninteractive solution.  It takes care of all three: --abort and --skip.\n We'd still need a --continue to non-interactively continue after a\nconflict resolution though, no?\n\n> Which is to say: if you have a story about what --abort will be used\n> for, the life of others evaluating the thing becomes better and the\n> upsides and downsides can be seen in perspective.  A story like \"am\n> and rebase have --abort, so cherry-pick should have one, too\" is\n> harder to think about.\n\nI agree.  There's little point in being stuck with historical\nconventions -- we should try something new and see how it works out :)\n\nThanks.\n\n-- Ram\n"},{"id":"169892","messageId":"20110612122145.GA20495@elie","threadId":"27602","inReplyTo":"BANLkTi=T0wCg1bKzmtQEQ-J-5ogqRZaqRg@mail.gmail.com","subject":"Re: [RFC PATCH v2] revert: Implement --abort processing","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-06-12T12:21:45Z","receivedAt":"2011-06-12T12:21:45Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n\n> My notion of --abort has changed: I simply want to remove the state\n> files for the cherry-pick so that the user can execute more\n> cherry-pick/ revert commands.  I didn't think a soft reset would be\n> intrusive.\n\nWell, if you understand this part then you can forget most of the\nrest of what I said.  Think about this for a second.  New user (or\nforgetful, experienced user), has just run\n\n\tgit cherry-pick HEAD..topic\n\nto integrate the changes from topic in a linear history.  Ran into\nconflicts, wanted to give up.  Ran\n\n\tgit cherry-pick --abort\n\nWould this person expect:\n\n - that \"git diff --cached\" would return a pile of changes\n - that \"git reset --keep\", \"git reset --merge\", \"git checkout\",\n   \"git merge\", and various other commands would refuse to do much,\n   for fear of clobbering the new \"local changes\"\n - that the worktree would be unchanged\n - etc\n\nWould they be happy about it?  Just put yourself in their shoes.  A\nsoft reset is near the most intrusive behavior possible.\n\nAnd that is a good way to think about the UI for any new facility.  If\nyou disregard about how flexible it is in abstract, how easy to\nimplement, how elegant-sounding and just think about a person using it\nwill find her quality of life improved or worsened, that is (1) a good\nsanity-check on a design and (2) basically the only way to explain it\nto other people.\n"},{"id":"169894","messageId":"BANLkTi=gYSJgG-Yu-+-5wPetpb0-AW=X+g@mail.gmail.com","threadId":"27602","inReplyTo":"20110612122145.GA20495@elie","subject":"Re: [RFC PATCH v2] revert: Implement --abort processing","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2011-06-12T12:51:57Z","receivedAt":"2011-06-12T12:51:57Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi again,\n\nJonathan Nieder writes:\n> Would this person expect:\n>\n>  - that \"git diff --cached\" would return a pile of changes\n>  - that \"git reset --keep\", \"git reset --merge\", \"git checkout\",\n>   \"git merge\", and various other commands would refuse to do much,\n>   for fear of clobbering the new \"local changes\"\n>  - that the worktree would be unchanged\n>  - etc\n>\n> Would they be happy about it?  Just put yourself in their shoes.  A\n> soft reset is near the most intrusive behavior possible.\n\nOkay, it sounds pretty terrible when you put it like that :p\n\n> And that is a good way to think about the UI for any new facility.  If\n> you disregard about how flexible it is in abstract, how easy to\n> implement, how elegant-sounding and just think about a person using it\n> will find her quality of life improved or worsened, that is (1) a good\n> sanity-check on a design and (2) basically the only way to explain it\n> to other people.\n\nFrankly, I'm still trying to understand how other people work -- I\ndon't use the porcelain much, and I dislike anything but the most\nminimalistic automation.  I didn't even like the change to cherry-pick\nwhere you can simply \"git commit\" after resolving a conflict; I still\nprefer and use the more explicit \"git commit -c\" after removing the\nCHERRY_PICK_HEAD.  Also, I *always* use rebase with --onto, because I\nexplicitly want to know how many commits I'm picking, and I often\ndon't remember if I've rewritten the ref I'm rebasing onto.  While\nrebasing, I use reset --hard a lot, because it's a very effective and\nwell-understood hammer; I then cherry-pick the refs I want from the\nreflog.  I don't know how others work; I think I'm completely confused\nabout UI because I'm trying to mix my personal tastes, historical\nconventions, and suggestions from others.\n</rant>\n\nLong story short: I'm hopeless at UI design. I'll think about the\nsequencer UI from a fresh perspective again, and hopefully post\nsomething sensible soon.\n\n-- Ram\n"},{"id":"169905","messageId":"20110612221217.GA2789@elie","threadId":"27602","inReplyTo":"BANLkTi=gYSJgG-Yu-+-5wPetpb0-AW=X+g@mail.gmail.com","subject":"Re: [RFC PATCH v2] revert: Implement --abort processing","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-06-12T22:12:17Z","receivedAt":"2011-06-12T22:12:17Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n\n> Frankly, I'm still trying to understand how other people work -- I\n> don't use the porcelain much, and I dislike anything but the most\n> minimalistic automation.  I didn't even like the change to cherry-pick\n> where you can simply \"git commit\" after resolving a conflict; I still\n> prefer and use the more explicit \"git commit -c\" after removing the\n> CHERRY_PICK_HEAD.  Also, I *always* use rebase with --onto\n\nI don't think that should stop you from thinking about how new\nfacilities help or interfere with work at all.  You use magit, right?\nIt automates all kinds of things.  And while each person is going to\nuse tools in different ways, that hasn't kept people from getting\nthings done in the past.\n\nIf you are thinking \"I would never use 'git cherry-pick --abort' --- I\nwould just look in the reflog for a commit to 'reset --hard' to\", then\nyou are *done*.  Just document it, make sure the reflog has useful\ncontent to help out, and wait until someone complains and adds a\nshortcut they like.\n\nAddendum:  Personally I was happy about \"git commit\" that implicitly\ntakes the commit message from CHERRY_PICK_HEAD because it adds a\n\n\tConflicts:\n\n\t\tMakefile\n\nthat I can use as a template for a message about the nature of the\nconflict and how I fixed it up.  As a side note, I'm curious about\nwhy you end up needing to remove the CHERRY_PICK_HEAD.  Is \"git commit\n-c interesting-patch\" misbehaving somehow?  (It should ignore the\nCHERRY_PICK_HEAD entirely.)\n"},{"id":"169944","messageId":"BANLkTim2SOAp3=g_zie-oi2=A9X7NVd5qw@mail.gmail.com","threadId":"27602","inReplyTo":"20110612221217.GA2789@elie","subject":"Re: [RFC PATCH v2] revert: Implement --abort processing","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2011-06-13T14:55:03Z","receivedAt":"2011-06-13T14:55:03Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi again,\n\nJonathan Nieder writes:\n> I don't think that should stop you from thinking about how new\n> facilities help or interfere with work at all.  You use magit, right?\n> It automates all kinds of things.  And while each person is going to\n> use tools in different ways, that hasn't kept people from getting\n> things done in the past.\n\nI use Magit only for staging, unstaging, committing, amending, and\nreverting portions.\n\n> If you are thinking \"I would never use 'git cherry-pick --abort' --- I\n> would just look in the reflog for a commit to 'reset --hard' to\", then\n> you are *done*.  Just document it, make sure the reflog has useful\n> content to help out, and wait until someone complains and adds a\n> shortcut they like.\n\nAh, thanks for the helpful advice. I'll stay away from deciding\nend-user interfaces altogether, and just write in the infrastructure\nfor sequencing commits with a minimalistic UI. People can add more\nlater :)\n\n> As a side note, I'm curious about\n> why you end up needing to remove the CHERRY_PICK_HEAD.  Is \"git commit\n> -c interesting-patch\" misbehaving somehow?  (It should ignore the\n> CHERRY_PICK_HEAD entirely.)\n\nSorry, I should have been clearer.  I remove the CHERRY_PICK_HEAD to\navoid hitting \"commit\", \"commit --amend\" by mistake.  With \"git commit\n-c\", it displays a pleasant message:\n\n# It looks like you may be committing a cherry-pick.\n# If this is not correct, please remove the file\n#\t.git/CHERRY_PICK_HEAD\n# and try again.\n\n-- Ram\n"},{"id":"169964","messageId":"20110613202806.GD11454@elie","threadId":"27602","inReplyTo":"BANLkTim2SOAp3=g_zie-oi2=A9X7NVd5qw@mail.gmail.com","subject":"Re: [RFC PATCH v2] revert: Implement --abort processing","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-06-13T20:28:06Z","receivedAt":"2011-06-13T20:28:06Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n> Jonathan Nieder writes:\n\n>> If you are thinking \"I would never use 'git cherry-pick --abort' --- I\n>> would just look in the reflog for a commit to 'reset --hard' to\", then\n>> you are *done*.  Just document it, make sure the reflog has useful\n>> content to help out, and wait until someone complains and adds a\n>> shortcut they like.\n>\n> Ah, thanks for the helpful advice. I'll stay away from deciding\n> end-user interfaces altogether, and just write in the infrastructure\n> for sequencing commits with a minimalistic UI. People can add more\n> later :)\n\nWell, until \"later\", this minimalistic UI is an end-user interface.\nSo just for the record, this does not mean you are free from writing\ndocumentation or thinking about processes that humans use for work.\n\nThat said, following a \"worse is better\" approach and just getting\nsomething simple working (meaning \"operable by human beings but not\nnecessarily perfect\") before adding the bells and whistles certainly\nmakes sense.  I'm not unhappy with that outcome.\n"}]}