{"thread":{"id":"26511","subject":"[RFC/PATCH 0/2] CHERRY_HEAD","startedAt":"2011-02-15T21:23:52Z","lastAt":"2011-02-17T14:09:40Z","messageCount":27,"participants":["Jay Soffian","Ævar Arnfjörð Bjarmason","Junio C Hamano","Jonathan Nieder","Bert Wesarg","Miles Bader","Christian Couder"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"161214","messageId":"1297805034-3512-1-git-send-email-jaysoffian@gmail.com","threadId":"26511","inReplyTo":null,"subject":"[RFC/PATCH 0/2] CHERRY_HEAD","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-15T21:23:52Z","receivedAt":"2011-02-15T21:23:52Z","isPatch":true,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"The user-experience after a cherry-pick conflicts is suboptimal.\nThe user has two choices for committing the resolved state:\n\n1. To retain the original authorship and commit message, the user can\n   'git commit -c <original commit id>'. This is what cherry-pick itself\n   advises. In this case MERGE_MSG (generated during the cherry-pick) is\n   ignored. That's bad since MERGE_MSG contains the list of conflicts \n   which is nice to have in the new commit. If 'cherry pick -x' was used,\n   the -x annotation is lost. Asking the user to remember the original\n   commit id is also a bit harsh.\n\n2. To reset the authorship, the user can 'git commit'. This will use the\n   MERGE_MSG, but the original authorship is lost.\n\nWe fix both of these issues by recording the original commit in CHERRY_HEAD\nif a conflict occurs during cherr-pick. We teach commit to use CHERRY_HEAD\nto retrieve the original authorship (unless --reset-author is used), but\ntake the commit message from MERGE_MSG.\n\nA further improvement would be to teach cherry-pick --continue and --abort\noptions a la rebase, but I think that should be prototyped in shell-script.\n\nJay Soffian (2):\n  Introduce CHERRY_HEAD\n  Teach commit to handle CHERRY_HEAD automatically\n\n Documentation/git-commit.txt           |    7 +++--\n branch.c                               |    1 +\n builtin/commit.c                       |   36 ++++++++++++++++++++++++++-----\n builtin/revert.c                       |   20 ++++++++++++++++-\n contrib/completion/git-completion.bash |    2 +\n 5 files changed, 55 insertions(+), 11 deletions(-)\n\n-- \n1.7.4.5.g9affb\n"},{"id":"161215","messageId":"1297805034-3512-2-git-send-email-jaysoffian@gmail.com","threadId":"26511","inReplyTo":"1297805034-3512-1-git-send-email-jaysoffian@gmail.com","subject":"[RFC/PATCH 1/2] Introduce CHERRY_HEAD","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-15T21:23:53Z","receivedAt":"2011-02-15T21:23:53Z","isPatch":true,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"When a cherry-pick conflicts git advises to use:\n\n $ git commit -c <original commit id>\n\nto preserve the original commit message and authorship. Instead,\nlet's record the original commit id in CHERRY_HEAD and advise to use:\n\n  $ git commit -c CHERRY_HEAD\n\nIn the next commit, we teach git to handle the '-c CHERRY_HEAD' part.\n---\n branch.c         |    1 +\n builtin/commit.c |    1 +\n builtin/revert.c |   23 ++++++++++++++++++++---\n 3 files changed, 22 insertions(+), 3 deletions(-)\n\ndiff --git a/branch.c b/branch.c\nindex 93dc866..81bbf95 100644\n--- a/branch.c\n+++ b/branch.c\n@@ -217,6 +217,7 @@ void create_branch(const char *head,\n \n void remove_branch_state(void)\n {\n+\tunlink(git_path(\"CHERRY_HEAD\"));\n \tunlink(git_path(\"MERGE_HEAD\"));\n \tunlink(git_path(\"MERGE_RR\"));\n \tunlink(git_path(\"MERGE_MSG\"));\ndiff --git a/builtin/commit.c b/builtin/commit.c\nindex 03cff5a..8850621 100644\n--- a/builtin/commit.c\n+++ b/builtin/commit.c\n@@ -1424,6 +1424,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)\n \t\tdie(\"cannot update HEAD ref\");\n \t}\n \n+\tunlink(git_path(\"CHERRY_HEAD\"));\n \tunlink(git_path(\"MERGE_HEAD\"));\n \tunlink(git_path(\"MERGE_MSG\"));\n \tunlink(git_path(\"MERGE_MODE\"));\ndiff --git a/builtin/revert.c b/builtin/revert.c\nindex dc1b702..c373e69 100644\n--- a/builtin/revert.c\n+++ b/builtin/revert.c\n@@ -248,6 +248,22 @@ static void set_author_ident_env(const char *message)\n \t\t\tsha1_to_hex(commit->object.sha1));\n }\n \n+static void write_cherry_head(void)\n+{\n+\tint fd;\n+\tstruct strbuf buf = STRBUF_INIT;\n+\n+\tstrbuf_addf(&buf, \"%s\\n\", sha1_to_hex(commit->object.sha1));\n+\n+\tfd = open(git_path(\"CHERRY_HEAD\"), O_WRONLY | O_CREAT, 0666);\n+\tif (fd < 0)\n+\t\tdie_errno(\"Could not open '%s' for writing\",\n+\t\t\t  git_path(\"CHERRY_HEAD\"));\n+\tif (write_in_full(fd, buf.buf, buf.len) != buf.len)\n+\t\tdie_errno(\"Could not write to '%s'\", git_path(\"CHERRY_HEAD\"));\n+\tclose(fd);\n+}\n+\n static void advise(const char *advice, ...)\n {\n \tva_list params;\n@@ -269,9 +285,10 @@ static void print_advice(void)\n \tadvise(\"after resolving the conflicts, mark the corrected paths\");\n \tadvise(\"with 'git add <paths>' or 'git rm <paths>'\");\n \n-\tif (action == CHERRY_PICK)\n-\t\tadvise(\"and commit the result with 'git commit -c %s'\",\n-\t\t       find_unique_abbrev(commit->object.sha1, DEFAULT_ABBREV));\n+\tif (action == CHERRY_PICK) {\n+\t\twrite_cherry_head();\n+\t\tadvise(\"and commit the result with 'git commit -c CHERRY_HEAD'\");\n+\t}\n }\n \n static void write_message(struct strbuf *msgbuf, const char *filename)\n-- \n1.7.4.5.g9affb\n"},{"id":"161216","messageId":"1297805034-3512-3-git-send-email-jaysoffian@gmail.com","threadId":"26511","inReplyTo":"1297805034-3512-1-git-send-email-jaysoffian@gmail.com","subject":"[RFC/PATCH 2/2] Teach commit to handle CHERRY_HEAD automatically","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-15T21:23:54Z","receivedAt":"2011-02-15T21:23:54Z","isPatch":true,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"Now that cherry-pick records the original commit id in CHERRY_HEAD\nfollowing a conflict, we can teach commit to handle it automatically.\n\nThe primary difference between this and 'commit -c CHERRY_HEAD'\n(besides saving the user some typing) is that we take only the\nauthorship from CHERRY_HEAD, while taking the commit message\nfrom MERGE_MSG (which contains the list of conflicts as well\nas cherry-pick -x's annotation, if -x was used).\n\n--reset-author can be used to reset authorship.\n---\nThere are several subtle interactions between the sundry commit options that\nmake my head hurt. I did my best to integrate what happens when there is\na CHERRY_HEAD, but I'm really not sure how CHERRY_HEAD ought to interact\nwith things like --squash and --fixup, or the message specifying options.\n\nFor example, it should probably be an error to use --squash/--fixup when\nthere's a CHERRY_HEAD, but then again, it should probably be an error to\nuse those options when there's a MERGE_HEAD (but it's not).\n\nOTOH, it seems valid to specify a commit message manually, so I allow that.\n\n Documentation/git-commit.txt           |    7 +++--\n builtin/commit.c                       |   35 ++++++++++++++++++++++++++-----\n builtin/revert.c                       |    5 +--\n contrib/completion/git-completion.bash |    2 +\n 4 files changed, 37 insertions(+), 12 deletions(-)\n\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex b586c0f..fd6a1f7 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -84,9 +84,10 @@ OPTIONS\n \tlinkgit:git-rebase[1] for details.\n \n --reset-author::\n-\tWhen used with -C/-c/--amend options, declare that the\n-\tauthorship of the resulting commit now belongs of the committer.\n-\tThis also renews the author timestamp.\n+\tWhen used with -C/-c/--amend options, or when committing after a\n+\ta conflicting cherry-pick, declare that the authorship of the\n+\tresulting commit now belongs of the committer. This also renews\n+\tthe author timestamp.\n \n --short::\n \tWhen doing a dry-run, give the output in the short-format. See\ndiff --git a/builtin/commit.c b/builtin/commit.c\nindex 8850621..2f0a8fc 100644\n--- a/builtin/commit.c\n+++ b/builtin/commit.c\n@@ -70,7 +70,7 @@ static const char *logfile, *force_author;\n static const char *template_file;\n static char *edit_message, *use_message;\n static char *fixup_message, *squash_message;\n-static int all, edit_flag, also, interactive, only, amend, signoff;\n+static int all, edit_flag, also, interactive, only, amend, signoff, cherry_pick;\n static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;\n static int no_post_rewrite, allow_empty_message;\n static char *untracked_files_arg, *force_date, *ignore_submodule_arg;\n@@ -609,7 +609,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,\n \t\t\tdie_errno(\"could not read log file '%s'\",\n \t\t\t\t  logfile);\n \t\thook_arg1 = \"message\";\n-\t} else if (use_message) {\n+\t} else if (use_message && !cherry_pick) {\n \t\tbuffer = strstr(use_message_buffer, \"\\n\\n\");\n \t\tif (!buffer || buffer[2] == '\\0')\n \t\t\tdie(\"commit has empty message\");\n@@ -704,6 +704,15 @@ static int prepare_to_commit(const char *index_file, const char *prefix,\n \t\t\t\t\"#\\n\",\n \t\t\t\tgit_path(\"MERGE_HEAD\"));\n \n+\t\tif (cherry_pick)\n+\t\t\tfprintf(fp,\n+\t\t\t\t\"#\\n\"\n+\t\t\t\t\"# It looks like you may be committing a cherry-pick.\\n\"\n+\t\t\t\t\"# If this is not correct, please remove the file\\n\"\n+\t\t\t\t\"#\t%s\\n\"\n+\t\t\t\t\"# and try again.\\n\"\n+\t\t\t\t\"#\\n\",\n+\t\t\t\tgit_path(\"CHERRY_HEAD\"));\n \t\tfprintf(fp,\n \t\t\t\"\\n\"\n \t\t\t\"# Please enter the commit message for your changes.\");\n@@ -898,6 +907,7 @@ static void handle_untracked_files_arg(struct wt_status *s)\n \t\tdie(\"Invalid untracked files mode '%s'\", untracked_files_arg);\n }\n \n+\n static int parse_and_validate_options(int argc, const char *argv[],\n \t\t\t\t      const char * const usage[],\n \t\t\t\t      const char *prefix,\n@@ -929,6 +939,8 @@ static int parse_and_validate_options(int argc, const char *argv[],\n \t\tdie(\"You have nothing to amend.\");\n \tif (amend && in_merge)\n \t\tdie(\"You are in the middle of a merge -- cannot amend.\");\n+\tif (amend && cherry_pick)\n+\t\tdie(\"You are in the middle of a cherry-pick -- cannot amend.\");\n \tif (fixup_message && squash_message)\n \t\tdie(\"Options --squash and --fixup cannot be used together\");\n \tif (use_message)\n@@ -943,11 +955,19 @@ static int parse_and_validate_options(int argc, const char *argv[],\n \t\tdie(\"Only one of -c/-C/-F/--fixup can be used.\");\n \tif (message.len && f > 0)\n \t\tdie(\"Option -m cannot be combined with -c/-C/-F/--fixup.\");\n+\tif (cherry_pick) {\n+\t\t/* Let message-specifying options override CHERRY_HEAD */\n+\t\tif (f > 0 || message.len)\n+\t\t\tcherry_pick = 0;\n+\t\telse\n+\t\t\t/* used for authorship side-effect only */\n+\t\t\tuse_message = \"CHERRY_HEAD\";\n+\t}\n \tif (edit_message)\n \t\tuse_message = edit_message;\n \tif (amend && !use_message && !fixup_message)\n \t\tuse_message = \"HEAD\";\n-\tif (!use_message && renew_authorship)\n+\tif (!use_message && !cherry_pick && renew_authorship)\n \t\tdie(\"--reset-author can be used only with -C, -c or --amend.\");\n \tif (use_message) {\n \t\tconst char *out_enc;\n@@ -1118,6 +1138,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)\n \tgitmodules_config();\n \tgit_config(git_status_config, &s);\n \tin_merge = file_exists(git_path(\"MERGE_HEAD\"));\n+\tcherry_pick = file_exists(git_path(\"CHERRY_HEAD\"));\n \targc = parse_options(argc, argv, prefix,\n \t\t\t     builtin_status_options,\n \t\t\t     builtin_status_usage, 0);\n@@ -1140,7 +1161,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)\n \t}\n \n \ts.is_initial = get_sha1(s.reference, sha1) ? 1 : 0;\n-\ts.in_merge = in_merge;\n+\ts.in_merge = in_merge || cherry_pick;\n \ts.ignore_submodule_arg = ignore_submodule_arg;\n \twt_status_collect(&s);\n \n@@ -1303,7 +1324,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)\n \twt_status_prepare(&s);\n \tgit_config(git_commit_config, &s);\n \tin_merge = file_exists(git_path(\"MERGE_HEAD\"));\n-\ts.in_merge = in_merge;\n+\tcherry_pick = file_exists(git_path(\"CHERRY_HEAD\"));\n+\ts.in_merge = in_merge || cherry_pick;\n \n \tif (s.use_color == -1)\n \t\ts.use_color = git_use_color_default;\n@@ -1369,7 +1391,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)\n \t\t\tparents = reduce_heads(parents);\n \t} else {\n \t\tif (!reflog_msg)\n-\t\t\treflog_msg = \"commit\";\n+\t\t\treflog_msg = cherry_pick ? \"commit (cherry-pick)\"\n+\t\t\t\t\t\t : \"commit\";\n \t\tpptr = &commit_list_insert(lookup_commit(head_sha1), pptr)->next;\n \t}\n \ndiff --git a/builtin/revert.c b/builtin/revert.c\nindex c373e69..678fc8e 100644\n--- a/builtin/revert.c\n+++ b/builtin/revert.c\n@@ -284,11 +284,10 @@ static void print_advice(void)\n \n \tadvise(\"after resolving the conflicts, mark the corrected paths\");\n \tadvise(\"with 'git add <paths>' or 'git rm <paths>'\");\n+\tadvice(\"and commit the result with 'git commit'\");\n \n-\tif (action == CHERRY_PICK) {\n+\tif (action == CHERRY_PICK)\n \t\twrite_cherry_head();\n-\t\tadvise(\"and commit the result with 'git commit -c CHERRY_HEAD'\");\n-\t}\n }\n \n static void write_message(struct strbuf *msgbuf, const char *filename)\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 893b771..1d446cf 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -246,6 +246,8 @@ __git_ps1 ()\n \t\t\t\tfi\n \t\t\telif [ -f \"$g/MERGE_HEAD\" ]; then\n \t\t\t\tr=\"|MERGING\"\n+\t\t\telif [ -f \"$g/CHERRY_HEAD\" ]; then\n+\t\t\t\tr=\"|CHERRY-PICKING\"\n \t\t\telif [ -f \"$g/BISECT_LOG\" ]; then\n \t\t\t\tr=\"|BISECTING\"\n \t\t\tfi\n-- \n1.7.4.5.g9affb\n"},{"id":"161218","messageId":"AANLkTik2NM+mxKgZy_9dCwydz+An4sFM_a4U9mdrJBq3@mail.gmail.com","threadId":"26511","inReplyTo":"1297805034-3512-1-git-send-email-jaysoffian@gmail.com","subject":"Re: [RFC/PATCH 0/2] CHERRY_HEAD","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2011-02-15T21:51:41Z","receivedAt":"2011-02-15T21:51:41Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Tue, Feb 15, 2011 at 22:23, Jay Soffian <jaysoffian@gmail.com> wrote:\n> The user-experience after a cherry-pick conflicts is suboptimal.\n> The user has two choices for committing the resolved state:\n\nI've read this over, haven't run it, but I really like the idea. It\nsucks that you have to save away the commit sha1 somwhere after a\nfailed cherry-pick to use it again. It should just behave like `git\nrebase --continue`, which this implements.\n\nIt'll need some tests as a non-RFC, but otherwise it looks good.\n"},{"id":"161219","messageId":"7vk4h1lzjj.fsf@alter.siamese.dyndns.org","threadId":"26511","inReplyTo":"AANLkTik2NM+mxKgZy_9dCwydz+An4sFM_a4U9mdrJBq3@mail.gmail.com","subject":"Re: [RFC/PATCH 0/2] CHERRY_HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-15T22:10:24Z","receivedAt":"2011-02-15T22:10:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> I've read this over, haven't run it, but I really like the idea. It\n> sucks that you have to save away the commit sha1 somwhere after a\n> failed cherry-pick to use it again. It should just behave like `git\n> rebase --continue`, which this implements.\n\nI don't understand.  What do you think rebase does to be able to continue?\nDoesn't it have to save the commit object name away somewhere?\n"},{"id":"161220","messageId":"AANLkTinV+cY-fND2bemDGdShnfqQGMG3eUmZPXrpKayt@mail.gmail.com","threadId":"26511","inReplyTo":"AANLkTik2NM+mxKgZy_9dCwydz+An4sFM_a4U9mdrJBq3@mail.gmail.com","subject":"Re: [RFC/PATCH 0/2] CHERRY_HEAD","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-15T22:11:36Z","receivedAt":"2011-02-15T22:11:36Z","isPatch":true,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Tue, Feb 15, 2011 at 4:51 PM, Ævar Arnfjörð Bjarmason\n<avarab@gmail.com> wrote:\n> I've read this over, haven't run it, but I really like the idea. It\n> sucks that you have to save away the commit sha1 somwhere after a\n> failed cherry-pick to use it again. It should just behave like `git\n> rebase --continue`, which this implements.\n\nI agree and I said as much. The problem is that cherry-pick has two\nmodes of behavior:\n\n1. Given a single commit. Historically this was the only way to use\nit. In this case, the behavior after a conflict should be the same as\nafter a merge conflict. You resolve the conflicts then use git commit.\n\n2. Given a rev-list. This is relatively recent addition to cherry-pick\n(7e2bfd3 revert: allow cherry-picking more than one commit,\n2010-06-02). Here's where I'd expect to have a more rebase-like\nbehavior, using --continue/abort to work through the sequence. But\nfrankly, I consider 7e2bfd3 a mistake. I think a better implementation\nwould be to make cherry-pick be plumbing, and re-use rebase's logic\nfor walking through the series of commit.\n\nI'd like to do (2) eventually[*] but I think in the mean time this is\na nice incremental improvement.\n\n[*] is the sequencer project dead?\n\n> It'll need some tests as a non-RFC, but otherwise it looks good.\n\nYep, I wanted to make sure I wasn't off in the weeds first. :-)\n\nThanks,\n\nj.\n"},{"id":"161222","messageId":"AANLkTin-9g9Ux=_oKBMuB+Yp-bOtBCTjqMWU7ENctXdM@mail.gmail.com","threadId":"26511","inReplyTo":"7vk4h1lzjj.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH 0/2] CHERRY_HEAD","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-15T22:13:30Z","receivedAt":"2011-02-15T22:13:30Z","isPatch":true,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Tue, Feb 15, 2011 at 5:10 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>\n>> I've read this over, haven't run it, but I really like the idea. It\n>> sucks that you have to save away the commit sha1 somwhere after a\n>> failed cherry-pick to use it again. It should just behave like `git\n>> rebase --continue`, which this implements.\n>\n> I don't understand.  What do you think rebase does to be able to continue?\n> Doesn't it have to save the commit object name away somewhere?\n\nI took it to mean that the behavior after a conflict should be 'add'\nfollowed by 'cherry-pick --continue', not 'add' followed by 'commit'.\nNot that I disagree, but that's a lot more work, see my reply to Ævar\njust before this.\n\nj.\n"},{"id":"161221","messageId":"7vfwrplze0.fsf@alter.siamese.dyndns.org","threadId":"26511","inReplyTo":"1297805034-3512-2-git-send-email-jaysoffian@gmail.com","subject":"Re: [RFC/PATCH 1/2] Introduce CHERRY_HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-15T22:13:43Z","receivedAt":"2011-02-15T22:13:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Introducing a new file that ends with _HEAD is fine, but shouldn't this be\nCHERRY_PICK_HEAD instead?\n"},{"id":"161223","messageId":"AANLkTim63v+jh1KROgVwwEyBDjVdge7MOq+DUnpw0c-e@mail.gmail.com","threadId":"26511","inReplyTo":"1297805034-3512-3-git-send-email-jaysoffian@gmail.com","subject":"Re: [RFC/PATCH 2/2] Teach commit to handle CHERRY_HEAD automatically","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-15T22:16:28Z","receivedAt":"2011-02-15T22:16:28Z","isPatch":true,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Tue, Feb 15, 2011 at 4:23 PM, Jay Soffian <jaysoffian@gmail.com> wrote:\n> --- a/builtin/revert.c\n> +++ b/builtin/revert.c\n> @@ -284,11 +284,10 @@ static void print_advice(void)\n>\n>        advise(\"after resolving the conflicts, mark the corrected paths\");\n>        advise(\"with 'git add <paths>' or 'git rm <paths>'\");\n> +       advice(\"and commit the result with 'git commit'\");\n\nObvious typo, I amended it but apparently ran format-patch before the\namend. Assuming the series is otherwise okay it'll be fixed in the\nre-roll with tests and SoB.\n\nj.\n"},{"id":"161224","messageId":"20110215221832.GA826@elie","threadId":"26511","inReplyTo":"1297805034-3512-2-git-send-email-jaysoffian@gmail.com","subject":"Re: [RFC/PATCH 1/2] Introduce CHERRY_HEAD","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-15T22:18:32Z","receivedAt":"2011-02-15T22:18:32Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jay Soffian wrote:\n\n> When a cherry-pick conflicts git advises to use:\n>\n>  $ git commit -c <original commit id>\n>\n> to preserve the original commit message and authorship. Instead,\n> let's record the original commit id in CHERRY_HEAD and advise to use:\n>\n>   $ git commit -c CHERRY_HEAD\n>\n> In the next commit, we teach git to handle the '-c CHERRY_HEAD' part.\n\nNice!  Thanks for working on this.\n\nI wonder if cherry-pick shouldn't also write MERGE_MSG or similar so\nthat gets taken care of automatically?  That would also allow options\nlike -x and -m to work better.\n\nSign-off?\n\n> +++ b/branch.c\n> @@ -217,6 +217,7 @@ void create_branch(const char *head,\n>\n>  void remove_branch_state(void)\n>  {\n> +\tunlink(git_path(\"CHERRY_HEAD\"));\n>  \tunlink(git_path(\"MERGE_HEAD\"));\n[...]\n> +++ b/builtin/commit.c\n> @@ -1424,6 +1424,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)\n[...]\n>  \n> +\tunlink(git_path(\"CHERRY_HEAD\"));\n>  \tunlink(git_path(\"MERGE_HEAD\"));\n\nAnother piece of code that checks for MERGE_HEAD is cmd_merge's\n\"You have not concluded your merge\" check.  Should it check for\nCHERRY_HEAD, too?\n\n> +++ b/builtin/revert.c\n> @@ -248,6 +248,22 @@ static void set_author_ident_env(const char *message)\n>  \t\t\tsha1_to_hex(commit->object.sha1));\n>  }\n>  \n> +static void write_cherry_head(void)\n> +{\n> +\tint fd;\n> +\tstruct strbuf buf = STRBUF_INIT;\n\nLeaked, I think.  I would have been tempted to put it in a char buf[50] ---\nwe can be glad you are writing this code. :)\n\nWith whatever subset of the following seems useful,\nReviewed-by: Jonathan Nieder <jrnieder@gmail.com>\n---\n Documentation/git-cherry-pick.txt |   19 +++++++++++++++++++\n Documentation/revisions.txt       |    5 ++++-\n builtin/merge.c                   |    7 +++++++\n builtin/revert.c                  |    4 ++--\n t/t3507-cherry-pick-conflict.sh   |   22 +++++++++++++++++++++-\n 5 files changed, 53 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt\nindex 749d68a..e8db99b 100644\n--- a/Documentation/git-cherry-pick.txt\n+++ b/Documentation/git-cherry-pick.txt\n@@ -16,6 +16,25 @@ Given one or more existing commits, apply the change each one\n introduces, recording a new commit for each.  This requires your\n working tree to be clean (no modifications from the HEAD commit).\n \n+When it is not obvious how to apply a change, the following\n+happens:\n+\n+1. The current branch and `HEAD` pointer stay at the last commit\n+   successfully made.\n+2. The `CHERRY_HEAD` ref is set to point at the commit that\n+   introduced the change that is difficult to apply.\n+3. Paths in which the change applied cleanly are updated both\n+   in the index file and in your working tree.\n+4. For conflicting paths, the index file records up to three\n+   versions, as described in the \"TRUE MERGE\" section of\n+   linkgit:git-merge[1].  The working tree files will include\n+   a description of the conflict bracketed by the usual\n+   conflict markers `<<<<<<<` and `>>>>>>>`.\n+5. No other modifications are made.\n+\n+See linkgit:git-merge[1] for some hints on resolving such\n+conflicts.\n+\n OPTIONS\n -------\n <commit>...::\ndiff --git a/Documentation/revisions.txt b/Documentation/revisions.txt\nindex 9e92734..02f0813 100644\n--- a/Documentation/revisions.txt\n+++ b/Documentation/revisions.txt\n@@ -25,7 +25,8 @@ blobs contained in a commit.\n   first match in the following rules:\n \n   . if `$GIT_DIR/<name>` exists, that is what you mean (this is usually\n-    useful only for `HEAD`, `FETCH_HEAD`, `ORIG_HEAD` and `MERGE_HEAD`);\n+    useful only for `HEAD`, `FETCH_HEAD`, `CHERRY_HEAD`, `ORIG_HEAD`\n+    and `MERGE_HEAD`);\n \n   . otherwise, `refs/<name>` if exists;\n \n@@ -40,6 +41,8 @@ blobs contained in a commit.\n HEAD names the commit your changes in the working tree is based on.\n FETCH_HEAD records the branch you fetched from a remote repository\n with your last 'git fetch' invocation.\n+CHERRY_HEAD records the commit you are applying the change from\n+when you run 'git cherry-pick'.\n ORIG_HEAD is created by commands that moves your HEAD in a drastic\n way, to record the position of the HEAD before their operation, so that\n you can change the tip of the branch back to the state before you ran\ndiff --git a/builtin/merge.c b/builtin/merge.c\nindex 9403747..cabfc9c 100644\n--- a/builtin/merge.c\n+++ b/builtin/merge.c\n@@ -971,6 +971,13 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n \t\telse\n \t\t\tdie(\"You have not concluded your merge (MERGE_HEAD exists).\");\n \t}\n+\tif (file_exists(git_path(\"CHERRY_HEAD\"))) {\n+\t\tif (advice_resolve_conflict)\n+\t\t\tdie(\"You have not concluded your cherry-pick (CHERRY_HEAD exists).\\n\"\n+\t\t\t    \"Please, commit your changes before you can merge.\");\n+\t\telse\n+\t\t\tdie(\"You have not concluded your cherry-pick (CHERRY_HEAD exists).\");\n+\t}\n \tresolve_undo_clear();\n \n \tif (verbosity < 0)\ndiff --git a/builtin/revert.c b/builtin/revert.c\nindex c373e69..04da0e1 100644\n--- a/builtin/revert.c\n+++ b/builtin/revert.c\n@@ -259,9 +259,9 @@ static void write_cherry_head(void)\n \tif (fd < 0)\n \t\tdie_errno(\"Could not open '%s' for writing\",\n \t\t\t  git_path(\"CHERRY_HEAD\"));\n-\tif (write_in_full(fd, buf.buf, buf.len) != buf.len)\n+\tif (write_in_full(fd, buf.buf, buf.len) != buf.len || close(fd))\n \t\tdie_errno(\"Could not write to '%s'\", git_path(\"CHERRY_HEAD\"));\n-\tclose(fd);\n+\tstrbuf_release(&buf);\n }\n \n static void advise(const char *advice, ...)\ndiff --git a/t/t3507-cherry-pick-conflict.sh b/t/t3507-cherry-pick-conflict.sh\nindex 607bf25..71a2167 100755\n--- a/t/t3507-cherry-pick-conflict.sh\n+++ b/t/t3507-cherry-pick-conflict.sh\n@@ -11,6 +11,12 @@ test_description='test cherry-pick and revert with conflicts\n \n . ./test-lib.sh\n \n+test_cmp_rev () {\n+\tgit rev-parse --verify \"$1\" >expect.rev &&\n+\tgit rev-parse --verify \"$2\" >actual.rev &&\n+\ttest_cmp expect.rev actual.rev\n+}\n+\n test_expect_success setup '\n \n \techo unrelated >unrelated &&\n@@ -51,13 +57,27 @@ test_expect_success 'advice from failed cherry-pick' \"\n \terror: could not apply \\$picked... picked\n \thint: after resolving the conflicts, mark the corrected paths\n \thint: with 'git add <paths>' or 'git rm <paths>'\n-\thint: and commit the result with 'git commit -c \\$picked'\n+\thint: and commit the result with 'git commit -c CHERRY_HEAD'\n \tEOF\n \ttest_must_fail git cherry-pick picked 2>actual &&\n \n \ttest_cmp expected actual\n \"\n \n+test_expect_success 'failed cherry-pick sets CHERRY_HEAD' '\n+\n+\tgit checkout -f initial^0 &&\n+\tgit read-tree -u --reset HEAD &&\n+\tgit clean -d -f -f -q -x &&\n+\n+\tgit update-index --refresh &&\n+\tgit diff-index --exit-code HEAD &&\n+\n+\ttest_must_fail git cherry-pick picked &&\n+\n+\ttest_cmp_rev picked CHERRY_HEAD\n+'\n+\n test_expect_success 'failed cherry-pick produces dirty index' '\n \n \tgit checkout -f initial^0 &&\n-- \n1.7.4.1\n"},{"id":"161225","messageId":"AANLkTin+mdE0wcahNmWWwOD5dZHfmeox=g9rX3h-rk28@mail.gmail.com","threadId":"26511","inReplyTo":"AANLkTin-9g9Ux=_oKBMuB+Yp-bOtBCTjqMWU7ENctXdM@mail.gmail.com","subject":"Re: [RFC/PATCH 0/2] CHERRY_HEAD","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2011-02-15T22:30:24Z","receivedAt":"2011-02-15T22:30:24Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Tue, Feb 15, 2011 at 23:13, Jay Soffian <jaysoffian@gmail.com> wrote:\n> On Tue, Feb 15, 2011 at 5:10 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>>\n>>> I've read this over, haven't run it, but I really like the idea. It\n>>> sucks that you have to save away the commit sha1 somwhere after a\n>>> failed cherry-pick to use it again. It should just behave like `git\n>>> rebase --continue`, which this implements.\n>>\n>> I don't understand.  What do you think rebase does to be able to continue?\n>> Doesn't it have to save the commit object name away somewhere?\n>\n> I took it to mean that the behavior after a conflict should be 'add'\n> followed by 'cherry-pick --continue', not 'add' followed by 'commit'.\n> Not that I disagree, but that's a lot more work, see my reply to Ævar\n> just before this.\n\nI just meant that when git-rebase conflicts it remembers the author\ninformation when you do --continue without you having to do `git\ncommit -c sha1-that-failed` or something.\n\nThis patch adds a similar thing to cherry-pick, which I like. It's a\nminor UI issue that's annoyed me in the past.\n"},{"id":"161226","messageId":"7v8vxhlyfx.fsf@alter.siamese.dyndns.org","threadId":"26511","inReplyTo":"1297805034-3512-3-git-send-email-jaysoffian@gmail.com","subject":"Re: [RFC/PATCH 2/2] Teach commit to handle CHERRY_HEAD automatically","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-15T22:34:10Z","receivedAt":"2011-02-15T22:34:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jay Soffian <jaysoffian@gmail.com> writes:\n\n> diff --git a/builtin/commit.c b/builtin/commit.c\n> index 8850621..2f0a8fc 100644\n> --- a/builtin/commit.c\n> +++ b/builtin/commit.c\n> @@ -70,7 +70,7 @@ static const char *logfile, *force_author;\n>  static const char *template_file;\n>  static char *edit_message, *use_message;\n>  static char *fixup_message, *squash_message;\n> -static int all, edit_flag, also, interactive, only, amend, signoff;\n> +static int all, edit_flag, also, interactive, only, amend, signoff, cherry_pick;\n\nThis doesn't belong here; it should come next to \"in_merge\" that marks us\nto be \"in the middle of concluding a merge\", and it probably is better to\ncall it \"in_cherry_pick\" to be consistent.\n\n> @@ -704,6 +704,15 @@ static int prepare_to_commit(const char *index_file, const char *prefix,\n>  \t\t\t\t\"#\\n\",\n>  \t\t\t\tgit_path(\"MERGE_HEAD\"));\n>  \n> +\t\tif (cherry_pick)\n> +\t\t\tfprintf(fp,\n> +\t\t\t\t\"#\\n\"\n> +\t\t\t\t\"# It looks like you may be committing a cherry-pick.\\n\"\n> +\t\t\t\t\"# If this is not correct, please remove the file\\n\"\n> +\t\t\t\t\"#\t%s\\n\"\n> +\t\t\t\t\"# and try again.\\n\"\n> +\t\t\t\t\"#\\n\",\n> +\t\t\t\tgit_path(\"CHERRY_HEAD\"));\n\nYeah, this shows clearly that in_merge is very similar to this new mode of\noperation.\n\n> @@ -929,6 +939,8 @@ static int parse_and_validate_options(int argc, const char *argv[],\n>  \t\tdie(\"You have nothing to amend.\");\n>  \tif (amend && in_merge)\n>  \t\tdie(\"You are in the middle of a merge -- cannot amend.\");\n> +\tif (amend && cherry_pick)\n> +\t\tdie(\"You are in the middle of a cherry-pick -- cannot amend.\");\n>  \tif (fixup_message && squash_message)\n>  \t\tdie(\"Options --squash and --fixup cannot be used together\");\n>  \tif (use_message)\n\nSo does this.\n\nMakes one wonder why the hunk that begins at line 609 special cases only\nthis new mode, no?\n\n> @@ -943,11 +955,19 @@ static int parse_and_validate_options(int argc, const char *argv[],\n>  \t\tdie(\"Only one of -c/-C/-F/--fixup can be used.\");\n>  \tif (message.len && f > 0)\n>  \t\tdie(\"Option -m cannot be combined with -c/-C/-F/--fixup.\");\n> +\tif (cherry_pick) {\n> +\t\t/* Let message-specifying options override CHERRY_HEAD */\n> +\t\tif (f > 0 || message.len)\n> +\t\t\tcherry_pick = 0;\n> +\t\telse\n> +\t\t\t/* used for authorship side-effect only */\n> +\t\t\tuse_message = \"CHERRY_HEAD\";\n> +\t}\n>  \tif (edit_message)\n>  \t\tuse_message = edit_message;\n>  \tif (amend && !use_message && !fixup_message)\n>  \t\tuse_message = \"HEAD\";\n> -\tif (!use_message && renew_authorship)\n> +\tif (!use_message && !cherry_pick && renew_authorship)\n>  \t\tdie(\"--reset-author can be used only with -C, -c or --amend.\");\n>  \tif (use_message) {\n>  \t\tconst char *out_enc;\n\nLikewise.  Perhaps these show that the way updated code uses the\nuse_message variable needs some rethinking.\n\n> @@ -1118,6 +1138,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)\n>  \tgitmodules_config();\n>  \tgit_config(git_status_config, &s);\n>  \tin_merge = file_exists(git_path(\"MERGE_HEAD\"));\n> +\tcherry_pick = file_exists(git_path(\"CHERRY_HEAD\"));\n>  \targc = parse_options(argc, argv, prefix,\n>  \t\t\t     builtin_status_options,\n>  \t\t\t     builtin_status_usage, 0);\n> @@ -1140,7 +1161,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)\n>  \t}\n>  \n>  \ts.is_initial = get_sha1(s.reference, sha1) ? 1 : 0;\n> -\ts.in_merge = in_merge;\n> +\ts.in_merge = in_merge || cherry_pick;\n\nUgly.  What does s.in_merge _MEAN_ after this patch gets applied?\n\nI am not at all opposed to extending the semantics of an existing field of\nthe structure (i.e. \"doing this and that when concluding a conflicted\nmerge made sense, and now we realize that doing exactly the same this and\nthat makes sense when concluding a conflicted cherry-pick\" is perfectly\nfine), but then that updated semantics should get a new name to cover both\nold and new use scenario.  You are _not_ in \"in-merge\" anymore but trying\nto get a behaviour from other parts of the system that is similar to what\nyou would get when \"in-merge\".  What is it?  That is what you should base\nthe new name for the field on.\n\n> @@ -1369,7 +1391,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)\n>  \t\t\tparents = reduce_heads(parents);\n>  \t} else {\n>  \t\tif (!reflog_msg)\n> -\t\t\treflog_msg = \"commit\";\n> +\t\t\treflog_msg = cherry_pick ? \"commit (cherry-pick)\"\n> +\t\t\t\t\t\t : \"commit\";\n\nThis seems to indicate that we don't say \"commit (merge)\" when concluding\na conflicted merge.  Shouldn't we?\n"},{"id":"161228","messageId":"7v4o84nbuh.fsf@alter.siamese.dyndns.org","threadId":"26511","inReplyTo":"20110215221832.GA826@elie","subject":"Re: [RFC/PATCH 1/2] Introduce CHERRY_HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-15T22:59:18Z","receivedAt":"2011-02-15T22:59:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> I wonder if cherry-pick shouldn't also write MERGE_MSG or similar so\n> that gets taken care of automatically?  That would also allow options\n> like -x and -m to work better.\n\nHm, that probably is a good idea.\n\n> diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt\n> index 749d68a..e8db99b 100644\n> --- a/Documentation/git-cherry-pick.txt\n> +++ b/Documentation/git-cherry-pick.txt\n> @@ -16,6 +16,25 @@ Given one or more existing commits, apply the change each one\n>  introduces, recording a new commit for each.  This requires your\n>  working tree to be clean (no modifications from the HEAD commit).\n>  \n> +When it is not obvious how to apply a change, the following\n> +happens:\n> +\n> +1. The current branch and `HEAD` pointer stay at the last commit\n> +   successfully made.\n> +2. The `CHERRY_HEAD` ref is set to point at the commit that\n> +   introduced the change that is difficult to apply.\n> +3. Paths in which the change applied cleanly are updated both\n> +   in the index file and in your working tree.\n> +4. For conflicting paths, the index file records up to three\n> +   versions, as described in the \"TRUE MERGE\" section of\n> +   linkgit:git-merge[1].  The working tree files will include\n> +   a description of the conflict bracketed by the usual\n> +   conflict markers `<<<<<<<` and `>>>>>>>`.\n\nWhat happened to the `=======`?  I thought you were copying and pasting\nfrom the said section.\n"},{"id":"161229","messageId":"20110215230015.GA17812@elie","threadId":"26511","inReplyTo":"1297805034-3512-3-git-send-email-jaysoffian@gmail.com","subject":"Re: [RFC/PATCH 2/2] Teach commit to handle CHERRY_HEAD automatically","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-15T23:00:15Z","receivedAt":"2011-02-15T23:00:15Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nSome quick thoughts.\n\nJay Soffian wrote:\n\n> Now that cherry-pick records the original commit id in CHERRY_HEAD\n> following a conflict, we can teach commit to handle it automatically.\n> \n> The primary difference between this and 'commit -c CHERRY_HEAD'\n> (besides saving the user some typing) is that we take only the\n> authorship from CHERRY_HEAD, while taking the commit message\n> from MERGE_MSG\n\nThis answers my question from before.\n\n[...]\n> For example, it should probably be an error to use --squash/--fixup when\n> there's a CHERRY_HEAD, but then again, it should probably be an error to\n> use those options when there's a MERGE_HEAD (but it's not).\n\nI see what you're saying about MERGE_HEAD --- it is not clear what is\nintended when a person asks \"rebase --autosquash\" to squash in a merge\ncommit.  With CHERRY_PICK_HEAD, it means \"after dealing with the\nconflict, I understand this commit better, and it ought to have been\nsquashed in with commit X\", no?\n\nThere is some potential for confusion from another direction.  The\nuncareful patch series maintainer can be tempted to try, after\nconflict resolution,\n\n - \"git commit --amend\" to say \"I'm done fixing the broken thing\".\n\n - \"git commit --fixup=HEAD/--squash=HEAD\" to say \"done fixing;\n   let's look at this again later and squash it when I am less\n   confused\".\n\nBoth are mistakes if HEAD is the previous and good commit rather than\nthe broken one.  Maybe there is some simple safety that could protect\nagainst them?\n\n> --- a/Documentation/git-commit.txt\n> +++ b/Documentation/git-commit.txt\n> @@ -84,9 +84,10 @@ OPTIONS\n>  \tlinkgit:git-rebase[1] for details.\n>\n>  --reset-author::\n> -\tWhen used with -C/-c/--amend options, declare that the\n> -\tauthorship of the resulting commit now belongs of the committer.\n> -\tThis also renews the author timestamp.\n> +\tWhen used with -C/-c/--amend options, or when committing after a\n> +\ta conflicting cherry-pick,\n\nor when committing after a conflicted merge, no?\n\n>                                  declare that the authorship of the\n> +\tresulting commit now belongs of the committer. This also renews\n> +\tthe author timestamp.\n\nHow does it interact with --author?\n\n> +++ b/builtin/commit.c\n[...]\n> @@ -609,7 +609,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,\n>  \t\t\tdie_errno(\"could not read log file '%s'\",\n>  \t\t\t\t  logfile);\n>  \t\thook_arg1 = \"message\";\n> -\t} else if (use_message) {\n> +\t} else if (use_message && !cherry_pick) {\n\nWouldn't this make\n\n\tgit commit -C foo\n\nafter a failed cherry-pick use MERGE_MSG instead of the message the\nuser requested?\n\n> @@ -704,6 +704,15 @@ static int prepare_to_commit(const char *index_file, const char *prefix,\n>  \t\t\t\t\"#\\n\",\n>  \t\t\t\tgit_path(\"MERGE_HEAD\"));\n>  \n> +\t\tif (cherry_pick)\n> +\t\t\tfprintf(fp,\n> +\t\t\t\t\"#\\n\"\n> +\t\t\t\t\"# It looks like you may be committing a cherry-pick.\\n\"\n\nAside: shouldn't we suggest some porcelain-ish command (git merge\n--clear?  git commit --no-merge?) to remove .git/MERGE_HEAD instead of\nasking the committer to do it?\n\nThis section is used to give a preview and sanity check for the\ncommit.\n\n - if we are on the wrong branch, that might be a mistake.\n - if the author is someone else, that might be a mistake.\n - if there are multiple parents, that might be a mistake.\n - if there are changes included, some might be mistakes.\n - if there are changes excluded, some might be mistakes,\n - if there are untracked files, some might be mistakes.\n\nWhere does committing a cherry-pick fall into that picture?  Maybe\n\n\t# Author:    A U Thor <author@example.com>\n\t# Date:      Tue Beb 9 01:23:45 1911 -0500\n\t#\n\t# If this is not correct, please try again using the\n\t# --author and --date or --reset-author options.\n\n> @@ -898,6 +907,7 @@ static void handle_untracked_files_arg(struct wt_status *s)\n>  \t\tdie(\"Invalid untracked files mode '%s'\", untracked_files_arg);\n>  }\n>  \n> +\n\nStray whitespace change?\n\n> @@ -929,6 +939,8 @@ static int parse_and_validate_options(int argc, const char *argv[],\n>  \t\tdie(\"You have nothing to amend.\");\n>  \tif (amend && in_merge)\n>  \t\tdie(\"You are in the middle of a merge -- cannot amend.\");\n> +\tif (amend && cherry_pick)\n> +\t\tdie(\"You are in the middle of a cherry-pick -- cannot amend.\");\n\nAh, this addresses the worry mentioned above.\n\nHow can I get out of this state if I really do want to amend?\n\n> @@ -943,11 +955,19 @@ static int parse_and_validate_options(int argc, const char *argv[],\n>  \t\tdie(\"Only one of -c/-C/-F/--fixup can be used.\");\n>  \tif (message.len && f > 0)\n>  \t\tdie(\"Option -m cannot be combined with -c/-C/-F/--fixup.\");\n> +\tif (cherry_pick) {\n> +\t\t/* Let message-specifying options override CHERRY_HEAD */\n> +\t\tif (f > 0 || message.len)\n> +\t\t\tcherry_pick = 0;\n> +\t\telse\n> +\t\t\t/* used for authorship side-effect only */\n> +\t\t\tuse_message = \"CHERRY_HEAD\";\n> +\t}\n\nHmm, what if I have commits F and F' and after trying to cherry-pick F\nI decide I want the message from F'?\n\n> @@ -1118,6 +1138,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)\n>  \tgitmodules_config();\n>  \tgit_config(git_status_config, &s);\n>  \tin_merge = file_exists(git_path(\"MERGE_HEAD\"));\n> +\tcherry_pick = file_exists(git_path(\"CHERRY_HEAD\"));\n\nIs it possible to be both in_merge and cherry_pick?\n\n> @@ -1369,7 +1391,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)\n>  \t\t\tparents = reduce_heads(parents);\n>  \t} else {\n>  \t\tif (!reflog_msg)\n> -\t\t\treflog_msg = \"commit\";\n> +\t\t\treflog_msg = cherry_pick ? \"commit (cherry-pick)\"\n> +\t\t\t\t\t\t : \"commit\";\n\nNice.  Probably worth mentioning in the commit message.\n\n> --- a/contrib/completion/git-completion.bash\n> +++ b/contrib/completion/git-completion.bash\n> @@ -246,6 +246,8 @@ __git_ps1 ()\n>  \t\t\t\tfi\n>  \t\t\telif [ -f \"$g/MERGE_HEAD\" ]; then\n>  \t\t\t\tr=\"|MERGING\"\n> +\t\t\telif [ -f \"$g/CHERRY_HEAD\" ]; then\n> +\t\t\t\tr=\"|CHERRY-PICKING\"\n\nLikewise.\n"},{"id":"161230","messageId":"AANLkTimZUhxkxuUMubmPxjd8MG0Pu=9mrLoPqi=MpPWZ@mail.gmail.com","threadId":"26511","inReplyTo":"7v4o84nbuh.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH 1/2] Introduce CHERRY_HEAD","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2011-02-15T23:02:27Z","receivedAt":"2011-02-15T23:02:27Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Tue, Feb 15, 2011 at 23:59, Junio C Hamano <gitster@pobox.com> wrote:\n> Jonathan Nieder <jrnieder@gmail.com> writes:\n>\n>> I wonder if cherry-pick shouldn't also write MERGE_MSG or similar so\n>> that gets taken care of automatically?  That would also allow options\n>> like -x and -m to work better.\n>\n> Hm, that probably is a good idea.\n>\n>> diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt\n>> index 749d68a..e8db99b 100644\n>> --- a/Documentation/git-cherry-pick.txt\n>> +++ b/Documentation/git-cherry-pick.txt\n>> @@ -16,6 +16,25 @@ Given one or more existing commits, apply the change each one\n>>  introduces, recording a new commit for each.  This requires your\n>>  working tree to be clean (no modifications from the HEAD commit).\n>>\n>> +When it is not obvious how to apply a change, the following\n>> +happens:\n>> +\n>> +1. The current branch and `HEAD` pointer stay at the last commit\n>> +   successfully made.\n>> +2. The `CHERRY_HEAD` ref is set to point at the commit that\n>> +   introduced the change that is difficult to apply.\n>> +3. Paths in which the change applied cleanly are updated both\n>> +   in the index file and in your working tree.\n>> +4. For conflicting paths, the index file records up to three\n>> +   versions, as described in the \"TRUE MERGE\" section of\n>> +   linkgit:git-merge[1].  The working tree files will include\n>> +   a description of the conflict bracketed by the usual\n>> +   conflict markers `<<<<<<<` and `>>>>>>>`.\n>\n> What happened to the `=======`?  I thought you were copying and pasting\n> from the said section.\n\nI think this is clear enough, else you would need to mention the\n'|||||||' and conflict_marker_size too.\n\nBert\n"},{"id":"161231","messageId":"AANLkTikUMoCC2-+oqX1dngC-zsSpx+T6gq2+o_r6B0uE@mail.gmail.com","threadId":"26511","inReplyTo":"7v4o84nbuh.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH 1/2] Introduce CHERRY_HEAD","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-15T23:07:19Z","receivedAt":"2011-02-15T23:07:19Z","isPatch":true,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Tue, Feb 15, 2011 at 5:59 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Jonathan Nieder <jrnieder@gmail.com> writes:\n>\n>> I wonder if cherry-pick shouldn't also write MERGE_MSG or similar so\n>> that gets taken care of automatically?  That would also allow options\n>> like -x and -m to work better.\n>\n> Hm, that probably is a good idea.\n\nI must not understand what either of you is asking. MERGE_MSG is\nwritten by cherry-pick already, it's just that it's ignored if you use\ncommit -c, as cherry-pick advises. (Before this patch series anyway.)\n\nj.\n"},{"id":"161232","messageId":"20110215230859.GB17812@elie","threadId":"26511","inReplyTo":"7v4o84nbuh.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH 1/2] Introduce CHERRY_HEAD","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-15T23:08:59Z","receivedAt":"2011-02-15T23:08:59Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> Jonathan Nieder <jrnieder@gmail.com> writes:\n\n>> I wonder if cherry-pick shouldn't also write MERGE_MSG or similar so\n>> that gets taken care of automatically?  That would also allow options\n>> like -x and -m to work better.\n>\n> Hm, that probably is a good idea.\n\nTurns out it already does. :)\n\n>> +++ b/Documentation/git-cherry-pick.txt\n>> @@ -16,6 +16,25 @@ Given one or more existing commits, apply the change each one\n[...]\n>> +When it is not obvious how to apply a change, the following\n>> +happens:\n>> +\n>> +1. The current branch and `HEAD` pointer stay at the last commit\n>> +   successfully made.\n>> +2. The `CHERRY_HEAD` ref is set to point at the commit that\n>> +   introduced the change that is difficult to apply.\n>> +3. Paths in which the change applied cleanly are updated both\n>> +   in the index file and in your working tree.\n>> +4. For conflicting paths, the index file records up to three\n>> +   versions, as described in the \"TRUE MERGE\" section of\n>> +   linkgit:git-merge[1].  The working tree files will include\n>> +   a description of the conflict bracketed by the usual\n>> +   conflict markers `<<<<<<<` and `>>>>>>>`.\n>\n> What happened to the `=======`?  I thought you were copying and pasting\n> from the said section.\n\nHmm, maybe as a temporary cop-out:\n\n\tWhat it is not obvious how to apply a change, the following\n\thappens:\n\n\t1. The current branch ...\n\t...\n\t3. Paths in which the change applied cleanly are updated both\n\t   in the index file and in your working tree.\n\t4. For conflicting paths, the index file and working tree\n\t   files record a description of the conflict, as described\n\t   in the \"TRUE MERGE\" section of linkgit:git-merge[1].\n\nI didn't want to copy and paste wholesale to avoid dull reading and to\navoid the two copies falling out of sync.  Maybe there should be a\npage on conflicts and their resolution for git-merge(1),\ngit-rebase(1), git-cherry-pick(1), and git-revert(1) to refer to?\n"},{"id":"161233","messageId":"7vzkpwlwqx.fsf@alter.siamese.dyndns.org","threadId":"26511","inReplyTo":"AANLkTimZUhxkxuUMubmPxjd8MG0Pu=9mrLoPqi=MpPWZ@mail.gmail.com","subject":"Re: [RFC/PATCH 1/2] Introduce CHERRY_HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-15T23:10:46Z","receivedAt":"2011-02-15T23:10:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bert Wesarg <bert.wesarg@googlemail.com> writes:\n\n>> What happened to the `=======`?  I thought you were copying and pasting\n>> from the said section.\n>\n> I think this is clear enough, else you would need to mention the\n> '|||||||' and conflict_marker_size too.\n\nIf so then probably the section this was copied from needs updating?\n"},{"id":"161235","messageId":"AANLkTinZ0ewJy01rV66xMMCKLon=7qz=hoJ3DbtXmtXL@mail.gmail.com","threadId":"26511","inReplyTo":"20110215230015.GA17812@elie","subject":"Re: [RFC/PATCH 2/2] Teach commit to handle CHERRY_HEAD automatically","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-15T23:21:54Z","receivedAt":"2011-02-15T23:21:54Z","isPatch":true,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Tue, Feb 15, 2011 at 6:00 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n>  - \"git commit --amend\" to say \"I'm done fixing the broken thing\".\n>\n>  - \"git commit --fixup=HEAD/--squash=HEAD\" to say \"done fixing;\n>   let's look at this again later and squash it when I am less\n>   confused\".\n>\n> Both are mistakes if HEAD is the previous and good commit rather than\n> the broken one.  Maybe there is some simple safety that could protect\n> against them?\n\nAs you see below, this is already protected against.\n\n>>  --reset-author::\n>> -     When used with -C/-c/--amend options, declare that the\n>> -     authorship of the resulting commit now belongs of the committer.\n>> -     This also renews the author timestamp.\n>> +     When used with -C/-c/--amend options, or when committing after a\n>> +     a conflicting cherry-pick,\n>\n> or when committing after a conflicted merge, no?\n\nNo. The person committing a merge is already the author of the merge,\nwhy would they use --reset-author?\n\n>\n>>                                  declare that the authorship of the\n>> +     resulting commit now belongs of the committer. This also renews\n>> +     the author timestamp.\n>\n> How does it interact with --author?\n\nNo change from before, --author forces the author of the new commit.\n\n>> +++ b/builtin/commit.c\n> [...]\n>> @@ -609,7 +609,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,\n>>                       die_errno(\"could not read log file '%s'\",\n>>                                 logfile);\n>>               hook_arg1 = \"message\";\n>> -     } else if (use_message) {\n>> +     } else if (use_message && !cherry_pick) {\n>\n> Wouldn't this make\n>\n>        git commit -C foo\n>\n> after a failed cherry-pick use MERGE_MSG instead of the message the\n> user requested?\n\nNo, because the -C will force the cherry_pick flag to 0 in\nparse_and_validate_options:\n\n\t\t/* Let message-specifying options override CHERRY_HEAD */\n\nI'll make this logic clearer though as I need to address Junio's\nearlier message.\n\n>> +             if (cherry_pick)\n>> +                     fprintf(fp,\n>> +                             \"#\\n\"\n>> +                             \"# It looks like you may be committing a cherry-pick.\\n\"\n>\n> Aside: shouldn't we suggest some porcelain-ish command (git merge\n> --clear?  git commit --no-merge?) to remove .git/MERGE_HEAD instead of\n> asking the committer to do it?\n\nWe have git merge --reset as an alias for reset --merge. Since reset\n--merge takes care of this case too (I think, I'll check) we can\nsuggest that for both.\n\n> This section is used to give a preview and sanity check for the\n> commit.\n>\n>  - if we are on the wrong branch, that might be a mistake.\n>  - if the author is someone else, that might be a mistake.\n>  - if there are multiple parents, that might be a mistake.\n>  - if there are changes included, some might be mistakes.\n>  - if there are changes excluded, some might be mistakes,\n>  - if there are untracked files, some might be mistakes.\n>\n> Where does committing a cherry-pick fall into that picture?  Maybe\n>\n>        # Author:    A U Thor <author@example.com>\n>        # Date:      Tue Beb 9 01:23:45 1911 -0500\n>        #\n>        # If this is not correct, please try again using the\n>        # --author and --date or --reset-author options.\n\nOkay.\n\n>> @@ -898,6 +907,7 @@ static void handle_untracked_files_arg(struct wt_status *s)\n>>               die(\"Invalid untracked files mode '%s'\", untracked_files_arg);\n>>  }\n>>\n>> +\n>\n> Stray whitespace change?\n\nIndeed.\n\n> How can I get out of this state if I really do want to amend?\n\ngit reset, same as it ever was?\n\n>> @@ -943,11 +955,19 @@ static int parse_and_validate_options(int argc, const char *argv[],\n>>               die(\"Only one of -c/-C/-F/--fixup can be used.\");\n>>       if (message.len && f > 0)\n>>               die(\"Option -m cannot be combined with -c/-C/-F/--fixup.\");\n>> +     if (cherry_pick) {\n>> +             /* Let message-specifying options override CHERRY_HEAD */\n>> +             if (f > 0 || message.len)\n>> +                     cherry_pick = 0;\n>> +             else\n>> +                     /* used for authorship side-effect only */\n>> +                     use_message = \"CHERRY_HEAD\";\n>> +     }\n>\n> Hmm, what if I have commits F and F' and after trying to cherry-pick F\n> I decide I want the message from F'?\n\nI don't think I understand. commit -c F', or just commit (w/o options)\nand you get MERGE_MSG generated by cherry-pick.\n\n>> @@ -1118,6 +1138,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)\n>>       gitmodules_config();\n>>       git_config(git_status_config, &s);\n>>       in_merge = file_exists(git_path(\"MERGE_HEAD\"));\n>> +     cherry_pick = file_exists(git_path(\"CHERRY_HEAD\"));\n>\n> Is it possible to be both in_merge and cherry_pick?\n\nNo, I need to rework this into an enum, maybe enum { CONFLICT_NONE,\nCONFLICT_MERGE, CONFLICT_CHERRY_PICK } conflict_type.\n\n>> -                     reflog_msg = \"commit\";\n>> +                     reflog_msg = cherry_pick ? \"commit (cherry-pick)\"\n>> +                                              : \"commit\";\n>\n> Nice.  Probably worth mentioning in the commit message.\n>\n>> +                     elif [ -f \"$g/CHERRY_HEAD\" ]; then\n>> +                             r=\"|CHERRY-PICKING\"\n>\n> Likewise.\n\nRight.\n\nThanks for the feedback!\n\nj.\n"},{"id":"161236","messageId":"AANLkTi=MzZdOKeWYDTXoE6kg+OCcnjTUsQax5oN-k5Jq@mail.gmail.com","threadId":"26511","inReplyTo":"7vzkpwlwqx.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH 1/2] Introduce CHERRY_HEAD","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2011-02-15T23:42:54Z","receivedAt":"2011-02-15T23:42:54Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Wed, Feb 16, 2011 at 00:10, Junio C Hamano <gitster@pobox.com> wrote:\n> Bert Wesarg <bert.wesarg@googlemail.com> writes:\n>\n>>> What happened to the `=======`?  I thought you were copying and pasting\n>>> from the said section.\n>>\n>> I think this is clear enough, else you would need to mention the\n>> '|||||||' and conflict_marker_size too.\n>\n> If so then probably the section this was copied from needs updating?\n>\n\nRight, the origin does not mention them too. It also uses just 3\ncharacters, instead of the default 7. I think using '<=>'/'<|=>' as a\nvisual hint about conflict markers should suffice here plus\nreferencing the next section. This next section\nHOW CONFLICTS ARE PRESENTED does describe both conflict styles but it\ndoesn't mention the conflict-marker-size option. There are more\nreferences in the documentation where only the RCS style is mentioned.\n\nAnyways, referencing \"TRUE MERGE\" alone is not enough, it should\nmention the following sections too, namely HOW CONFLICTS ARE PRESENTED\nand HOW TO RESOLVE CONFLICTS. In German we would do this by '\"TRUE\nMERGE\" ff.' Where 'ff.' is the plural of the abbreviation for\n'following'. I don't know how to do that in English.\n\nAlso I'm wondering, why the git repo does not set the\nconflict-marker-size for its offending files itself. The current\noffender would be:\n\n$ git grep -l '^<<<<<<<' Documentation/\nDocumentation/git-merge-file.txt\nDocumentation/git-merge.txt\nDocumentation/user-manual.txt\n\nI may provide a patch in the future, if no one beats me.\n\nBert\n"},{"id":"161237","messageId":"20110215234735.GA18151@elie","threadId":"26511","inReplyTo":"AANLkTinZ0ewJy01rV66xMMCKLon=7qz=hoJ3DbtXmtXL@mail.gmail.com","subject":"Re: [RFC/PATCH 2/2] Teach commit to handle CHERRY_HEAD automatically","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-15T23:47:35Z","receivedAt":"2011-02-15T23:47:35Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nThanks for a quick response.  Some small clarifications.\n\nJay Soffian wrote:\n> On Tue, Feb 15, 2011 at 6:00 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n\n>>  - \"git commit --amend\" to say \"I'm done fixing the broken thing\".\n>>\n>>  - \"git commit --fixup=HEAD/--squash=HEAD\" to say \"done fixing;\n>>   let's look at this again later and squash it when I am less\n>>   confused\".\n>>\n>> Both are mistakes if HEAD is the previous and good commit rather than\n>> the broken one.  Maybe there is some simple safety that could protect\n>> against them?\n>\n> As you see below, this is already protected against.\n\nThe first mistake is protected against[*], the second left alone.\n(The second seems mostly harmless; just mentioning it for reference.)\n\n[*] which I think is my favorite part of this patch\n\n>>>  --reset-author::\n>>> +     When used with -C/-c/--amend options, or when committing after a\n>>> +     a conflicting cherry-pick,\n>>\n>> or when committing after a conflicted merge, no?\n>\n> No. The person committing a merge is already the author of the merge,\n> why would they use --reset-author?\n\nYou're right.  I find myself occasionally doing the following\n\n\tgit merge --no-commit $branch\n\t... update version number; walk away for a while  ...\n\tgit commit;\t# will this use the old timestamp?\n\tgit commit --amend --reset-author\n\nout of a vague fear, but I think I was just confused.\n\n>>>                                  declare that the authorship of the\n>>> +     resulting commit now belongs of the committer. This also renews\n>>> +     the author timestamp.\n>>\n>> How does it interact with --author?\n>\n> No change from before, --author forces the author of the new commit.\n\nPatch below.\n\n[...]\n> \t\t/* Let message-specifying options override CHERRY_HEAD */\n>\n> I'll make this logic clearer though as I need to address Junio's\n> earlier message.\n\nAh, good to hear.\n\n>>> +             if (cherry_pick)\n>>> +                     fprintf(fp,\n>>> +                             \"#\\n\"\n>>> +                             \"# It looks like you may be committing a cherry-pick.\\n\"\n>>\n>> Aside: shouldn't we suggest some porcelain-ish command (git merge\n>> --clear?  git commit --no-merge?) to remove .git/MERGE_HEAD instead of\n>> asking the committer to do it?\n>\n> We have git merge --reset as an alias for reset --merge. Since reset\n> --merge takes care of this case too (I think, I'll check) we can\n> suggest that for both.\n\nNo, I think \"git merge --abort\" does too much.  If we were ready to\ncommit, we almost surely have precious staged changes that it would\nremove.\n\nThe cure to a lingering MERGE_HEAD is still \"rm -f .git/MERGE_HEAD\",\nI fear.  \"git commit --no-merge\" (meaning \"ignore MERGE_HEAD\") seems\ntempting.\n\n>> How can I get out of this state if I really do want to amend?\n>\n> git reset, same as it ever was?\n\nNot obvious at all.  Maybe the manpage to cherry-pick could mention\nthat CHERRY_HEAD is cleared away by git reset?\n\n>> Hmm, what if I have commits F and F' and after trying to cherry-pick F\n>> I decide I want the message from F'?\n>\n> I don't think I understand. commit -c F', or just commit (w/o options)\n> and you get MERGE_MSG generated by cherry-pick.\n\nI meant the following sequence of operations:\n\n\t# by the way, does this set CHERRY_PICK_HEAD?\n\tgit cherry-pick --no-commit F\n\tgit commit -C F-prime\n\nBut that was a silly example --- -C takes care of authorship on its\nown.  A better example might be\n\n\tgit cherry-pick --no-commit F\n\tgit commit -F the-message\n\nor\n\n\tgit cherry-pick --no-commit F\n\tgit commit --amend -C F-prime\n\n> Thanks for the feedback!\n\nThanks for making it happen. :)\nJonathan\n"},{"id":"161242","messageId":"AANLkTinrQ4hSh-dg6mU=gYi6C8ZWS4eFKbAV=8eucEg2@mail.gmail.com","threadId":"26511","inReplyTo":"20110215234735.GA18151@elie","subject":"Re: [RFC/PATCH 2/2] Teach commit to handle CHERRY_HEAD automatically","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-16T00:03:08Z","receivedAt":"2011-02-16T00:03:08Z","isPatch":true,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Tue, Feb 15, 2011 at 6:47 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n> I meant the following sequence of operations:\n>\n>        # by the way, does this set CHERRY_PICK_HEAD?\n>        git cherry-pick --no-commit F\n>        git commit -C F-prime\n\nCHERRY_PICK_HEAD is not written if you use --no-commit.  I'm going to\npunt here and say that's not my itch, thus...\n\n> But that was a silly example --- -C takes care of authorship on its\n> own.  A better example might be\n>\n>        git cherry-pick --no-commit F\n>        git commit -F the-message\n>\n> or\n>\n>        git cherry-pick --no-commit F\n>        git commit --amend -C F-prime\n\n\nBecause CHERRY_PICK_HEAD wasn't written, commit in this case behaves\nas it did before this series.\n\nj.\n"},{"id":"161243","messageId":"20110216000553.GB18151@elie","threadId":"26511","inReplyTo":"20110215234735.GA18151@elie","subject":"[PATCH] Documentation: clarify interaction of --reset-author with --author","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-16T00:05:53Z","receivedAt":"2011-02-16T00:05:53Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"The --author and --date options override the author and date from\n--reset-author.\n\nSigned-off-by: Jonathan Nieder <jrnieder@gmail.com>\n---\nJonathan Nieder wrote:\n\n> Patch below.\n\nSane?\n\n Documentation/git-commit.txt |    7 +++++--\n 1 files changed, 5 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex b586c0f..f766d53 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -84,9 +84,12 @@ OPTIONS\n \tlinkgit:git-rebase[1] for details.\n \n --reset-author::\n-\tWhen used with -C/-c/--amend options, declare that the\n-\tauthorship of the resulting commit now belongs of the committer.\n+\tDespite use of the -c, -C, or --amend option, declare that the\n+\tauthorship of the new commit belongs to the committer.\n \tThis also renews the author timestamp.\n++\n+Can be combined with `--author` or `--date` to claim authorship using\n+some specific name and email address or date.\n \n --short::\n \tWhen doing a dry-run, give the output in the short-format. See\n-- \n1.7.4.1\n"},{"id":"161244","messageId":"20110216000859.GC18151@elie","threadId":"26511","inReplyTo":"AANLkTinrQ4hSh-dg6mU=gYi6C8ZWS4eFKbAV=8eucEg2@mail.gmail.com","subject":"Re: [RFC/PATCH 2/2] Teach commit to handle CHERRY_HEAD automatically","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-16T00:08:59Z","receivedAt":"2011-02-16T00:08:59Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jay Soffian wrote:\n\n> CHERRY_PICK_HEAD is not written if you use --no-commit.  I'm going to\n> punt here and say that's not my itch, thus...\n>\n> On Tue, Feb 15, 2011 at 6:47 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n\n>> But that was a silly example --- -C takes care of authorship on its\n>> own.  A better example might be\n>>\n>>        git cherry-pick --no-commit F\n>>        git commit -F the-message\n>>\n>> or\n>>\n>>        git cherry-pick --no-commit F\n>>        git commit --amend -C F-prime\n>\n> Because CHERRY_PICK_HEAD wasn't written, commit in this case behaves\n> as it did before this series.\n\nI'll just wait for the reroll and try it.  But surely it is clear what\nI am asking?\n\n\tgit cherry-pick conflicting-thing\n\t... fix conflict ...\n\tgit commit -F message\n\nshould either error out or respect the user's wish, and likewise\n\n\tgit cherry-pick conflicting-thing\n\t... fix conflict ...\n\tgit commit --amend -C something-else\n\nshould error out.\n"},{"id":"161246","messageId":"7vhbc4lrh4.fsf@alter.siamese.dyndns.org","threadId":"26511","inReplyTo":"20110216000553.GB18151@elie","subject":"Re: [PATCH] Documentation: clarify interaction of --reset-author with --author","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-16T01:04:39Z","receivedAt":"2011-02-16T01:04:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> The --author and --date options override the author and date from\n> --reset-author.\n>\n> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>\n> ---\n> Jonathan Nieder wrote:\n>\n>> Patch below.\n>\n> Sane?\n\nThe option is about reusing only the message and determine authorship\ninformation from usual means, so in that sense it is sane.  A command line\n\"commit -C $that_one --reset-author --date=yesterday --author=$him\" would\nmake sense in practice, but if you give both explicitly, you don't need\nan explicit --reset-author anymore, so overall it makes sense in a funny\nway.\n\n>  Documentation/git-commit.txt |    7 +++++--\n>  1 files changed, 5 insertions(+), 2 deletions(-)\n>\n> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\n> index b586c0f..f766d53 100644\n> --- a/Documentation/git-commit.txt\n> +++ b/Documentation/git-commit.txt\n> @@ -84,9 +84,12 @@ OPTIONS\n>  \tlinkgit:git-rebase[1] for details.\n>  \n>  --reset-author::\n> -\tWhen used with -C/-c/--amend options, declare that the\n> -\tauthorship of the resulting commit now belongs of the committer.\n> +\tDespite use of the -c, -C, or --amend option, declare that the\n> +\tauthorship of the new commit belongs to the committer.\n>  \tThis also renews the author timestamp.\n> ++\n> +Can be combined with `--author` or `--date` to claim authorship using\n> +some specific name and email address or date.\n>  \n>  --short::\n>  \tWhen doing a dry-run, give the output in the short-format. See\n> -- \n> 1.7.4.1\n"},{"id":"161249","messageId":"87oc6czr4j.fsf@catnip.gol.com","threadId":"26511","inReplyTo":"AANLkTinV+cY-fND2bemDGdShnfqQGMG3eUmZPXrpKayt@mail.gmail.com","subject":"Re: [RFC/PATCH 0/2] CHERRY_HEAD","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2011-02-16T01:48:28Z","receivedAt":"2011-02-16T01:48:28Z","isPatch":true,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Jay Soffian <jaysoffian@gmail.com> writes:\n> 2. Given a rev-list. This is relatively recent addition to cherry-pick\n> (7e2bfd3 revert: allow cherry-picking more than one commit,\n> 2010-06-02). Here's where I'd expect to have a more rebase-like\n> behavior, using --continue/abort to work through the sequence. But\n> frankly, I consider 7e2bfd3 a mistake. I think a better implementation\n> would be to make cherry-pick be plumbing, and re-use rebase's logic\n> for walking through the series of commit.\n\nI'd also love this functionality ... \n\nCan basically do it with:\n\n  # remember current branch name CHERRY_PICK_TARGET\n  git checkout REV_LIST_END\n  git rebase --onto CHERRY_PICK_TARGET  REV_LIST_START\n  [+ git rebase --continue etc]\n\nbut man, is that confusing to remember...\n\nI wonder if a wrapper would be robust enough.\n\n-Miles\n\n-- \nCannon, n. An instrument employed in the rectification of national boundaries.\n"},{"id":"161424","messageId":"AANLkTikWX-Pzok6MZofMD_=pPSvC5iANbzKbs0wgrZ4Q@mail.gmail.com","threadId":"26511","inReplyTo":"AANLkTinV+cY-fND2bemDGdShnfqQGMG3eUmZPXrpKayt@mail.gmail.com","subject":"Re: [RFC/PATCH 0/2] CHERRY_HEAD","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2011-02-17T14:09:40Z","receivedAt":"2011-02-17T14:09:40Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Tue, Feb 15, 2011 at 11:11 PM, Jay Soffian <jaysoffian@gmail.com> wrote:\n> On Tue, Feb 15, 2011 at 4:51 PM, Ævar Arnfjörð Bjarmason\n> <avarab@gmail.com> wrote:\n>> I've read this over, haven't run it, but I really like the idea. It\n>> sucks that you have to save away the commit sha1 somwhere after a\n>> failed cherry-pick to use it again. It should just behave like `git\n>> rebase --continue`, which this implements.\n>\n> I agree and I said as much. The problem is that cherry-pick has two\n> modes of behavior:\n>\n> 1. Given a single commit. Historically this was the only way to use\n> it. In this case, the behavior after a conflict should be the same as\n> after a merge conflict. You resolve the conflicts then use git commit.\n>\n> 2. Given a rev-list. This is relatively recent addition to cherry-pick\n> (7e2bfd3 revert: allow cherry-picking more than one commit,\n> 2010-06-02). Here's where I'd expect to have a more rebase-like\n> behavior, using --continue/abort to work through the sequence. But\n> frankly, I consider 7e2bfd3 a mistake. I think a better implementation\n> would be to make cherry-pick be plumbing, and re-use rebase's logic\n> for walking through the series of commit.\n\nMany people wanted to be able to cherry pick many commits, so it seems\nlogical to make cherry-pick accept a range of commits.\n\nAbout the implementation, it's better if it's in C. And it's true that\nit would be better if rebase and cherry-pick could use the same logic\nand even share the same code, but that's exactly what the goal of the\nsequencer project has been.\n\nI started to implement cherry-pick --continue and posted some RFC WIP\npatches last november:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/162183/focus=162197\n\nthe goal is to have something that in the end can be reused by rebase,\nam and perhaps other commands.\n\nI did some work on it after that, but I got stalled and had not much\ntime during the last months to move it further. I will see if I can\nfind time to work on it during the next weeks and/or publish/post the\ncurrent state.\n\n> I'd like to do (2) eventually[*] but I think in the mean time this is\n> a nice incremental improvement.\n>\n> [*] is the sequencer project dead?\n\nIf you are interested, perhaps you can have a look at what I posted\nlast november. And if you want to work on it you can ask me to publish\nthe current state, and eventually base some of your work on that.\n\nThanks,\nChristian.\n"}]}