{"thread":{"id":"42477","subject":"error: Can't cherry-pick into empty head","startedAt":"2016-05-28T17:54:40Z","lastAt":"2016-06-07T07:03:28Z","messageCount":7,"participants":["Fabrizio Cucci","Michael J Gruber","Torsten Bögershausen","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"287751","messageId":"CAOxYW4yTCMYcY=9YvwHNK5rKDK0_f-Uc7L92-QuQkv_hwCV+HA@mail.gmail.com","threadId":"42477","inReplyTo":null,"subject":"error: Can't cherry-pick into empty head","fromName":"Fabrizio Cucci","fromEmail":"fabrizio.cucci@gmail.com","sentAt":"2016-05-28T17:54:40Z","receivedAt":"2016-05-28T17:54:40Z","isPatch":false,"sender":{"key":"fabrizio.cucci@gmail.com","avatar":null},"body":"Hello everyone,\n\nI'm trying to understand why I'm getting the error as per subject.\n\nThe scenario is the following: I'm on the master branch (which\ncontains several commits) and I would like to create a new empty\nbranch (let's call it new-orphan) and cherry-pick only the commits\nrelated to a specific folder (let's call it my-folder) from the master\nbranch.\n\nSo, I tried the following command sequence:\n\n  master $ git checkout --orphan new-orphan\n  new-orphan $ git rm --cached -r .\n  new-orphan $ git clean -df\n\nAfter confirming that I'm in a clean state (with \"$ git status\") I tried:\n\n  new-orphan $ git rev-list --reverse master -- my-folder/ | git\ncherry-pick --stdin\n\nas suggested https://git-scm.com/docs/git-cherry-pick, but what I get\nis \"error: Can't cherry-pick into empty head\".\n\nWhat I don't really understand is:\n\n1) if I cherry-pick a single commit instead of multiple commits,\neverything works fine:\n\n  new-orphan $ git cherry-pick <some-commit-id>\n\n2) if I commit something before trying the above command, everything works fine:\n\n  new-orphan $ touch README\n  new-orphan $ git add README\n  new-orphan $ git commit -m \"added README\"\n  new-orphan $ git rev-list --reverse master -- my-folder/ | git\ncherry-pick --stdin\n\nCan someone please help me understand this?\n\nThanks,\nFabrizio\n"},{"id":"288426","messageId":"afafa51c-f950-594e-7142-5b28b1182add@drmicha.warpmail.net","threadId":"42477","inReplyTo":"CAOxYW4yTCMYcY=9YvwHNK5rKDK0_f-Uc7L92-QuQkv_hwCV+HA@mail.gmail.com","subject":"Re: error: Can't cherry-pick into empty head","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2016-06-06T13:21:44Z","receivedAt":"2016-06-06T13:21:44Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Fabrizio Cucci venit, vidit, dixit 28.05.2016 19:54:\n> Hello everyone,\n> \n> I'm trying to understand why I'm getting the error as per subject.\n> \n> The scenario is the following: I'm on the master branch (which\n> contains several commits) and I would like to create a new empty\n> branch (let's call it new-orphan) and cherry-pick only the commits\n> related to a specific folder (let's call it my-folder) from the master\n> branch.\n> \n> So, I tried the following command sequence:\n> \n>   master $ git checkout --orphan new-orphan\n>   new-orphan $ git rm --cached -r .\n>   new-orphan $ git clean -df\n> \n> After confirming that I'm in a clean state (with \"$ git status\") I tried:\n> \n>   new-orphan $ git rev-list --reverse master -- my-folder/ | git\n> cherry-pick --stdin\n> \n> as suggested https://git-scm.com/docs/git-cherry-pick, but what I get\n> is \"error: Can't cherry-pick into empty head\".\n> \n> What I don't really understand is:\n> \n> 1) if I cherry-pick a single commit instead of multiple commits,\n> everything works fine:\n> \n>   new-orphan $ git cherry-pick <some-commit-id>\n> \n> 2) if I commit something before trying the above command, everything works fine:\n> \n>   new-orphan $ touch README\n>   new-orphan $ git add README\n>   new-orphan $ git commit -m \"added README\"\n>   new-orphan $ git rev-list --reverse master -- my-folder/ | git\n> cherry-pick --stdin\n> \n> Can someone please help me understand this?\n\nThe implementation for the single commit and multiple commit cases is\ndifferent (so that you can do a single cherry-pick from with a running\ncherry-pick sequence). As a side effect, the single commit pick does not\ncare about an empty head.\n\nI'll follow up with a patch which changes that.\n\nMichael\n"},{"id":"288427","messageId":"69f7973e353f52a62157ca59af5027c9617506a4.1465219182.git.git@drmicha.warpmail.net","threadId":"42477","inReplyTo":"afafa51c-f950-594e-7142-5b28b1182add@drmicha.warpmail.net","subject":"[PATCH] cherry-pick: allow to pick to unborn branches","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2016-06-06T13:23:54Z","receivedAt":"2016-06-06T13:23:54Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Currently, cherry-pick allows tp pick single commits to an empty HEAD\nbut not multiple commits.\n\nAllow the multiple commit case, too.\n\nReported-by: Fabrizio Cucci <fabrizio.cucci@gmail.com>\nSigned-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n---\n sequencer.c | 11 ++++++-----\n 1 file changed, 6 insertions(+), 5 deletions(-)\n\ndiff --git a/sequencer.c b/sequencer.c\nindex 4687ad4..c6362d6 100644\n--- a/sequencer.c\n+++ b/sequencer.c\n@@ -888,6 +888,10 @@ static int sequencer_rollback(struct replay_opts *opts)\n \t\t\tgit_path_head_file());\n \t\tgoto fail;\n \t}\n+\tif (is_null_sha1(sha1)) {\n+\t\terror(_(\"cannot abort from a branch yet to be born\"));\n+\t\tgoto fail;\n+\t}\n \tif (reset_for_rollback(sha1))\n \t\tgoto fail;\n \tremove_sequencer_state();\n@@ -1086,11 +1090,8 @@ int sequencer_pick_revisions(struct replay_opts *opts)\n \twalk_revs_populate_todo(&todo_list, opts);\n \tif (create_seq_dir() < 0)\n \t\treturn -1;\n-\tif (get_sha1(\"HEAD\", sha1)) {\n-\t\tif (opts->action == REPLAY_REVERT)\n-\t\t\treturn error(_(\"Can't revert as initial commit\"));\n-\t\treturn error(_(\"Can't cherry-pick into empty head\"));\n-\t}\n+\tif (get_sha1(\"HEAD\", sha1) && (opts->action == REPLAY_REVERT))\n+\t\treturn error(_(\"Can't revert as initial commit\"));\n \tsave_head(sha1_to_hex(sha1));\n \tsave_opts(opts);\n \treturn pick_commits(todo_list, opts);\n-- \n2.9.0.rc1.371.ge0ee742\n"},{"id":"288436","messageId":"303a47c2-b878-6dc9-abb0-0d948866c197@web.de","threadId":"42477","inReplyTo":"69f7973e353f52a62157ca59af5027c9617506a4.1465219182.git.git@drmicha.warpmail.net","subject":"Re: [PATCH] cherry-pick: allow to pick to unborn branches","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2016-06-06T15:11:12Z","receivedAt":"2016-06-06T15:11:12Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 06.06.16 15:23, Michael J Gruber wrote:\n> Currently, cherry-pick allows tp pick single commits to an empty HEAD\nTypo:                           ^^\n"},{"id":"288481","messageId":"xmqq7fe2w087.fsf@gitster.mtv.corp.google.com","threadId":"42477","inReplyTo":"69f7973e353f52a62157ca59af5027c9617506a4.1465219182.git.git@drmicha.warpmail.net","subject":"Re: [PATCH] cherry-pick: allow to pick to unborn branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-06-06T20:06:48Z","receivedAt":"2016-06-06T20:06:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n> Currently, cherry-pick allows tp pick single commits to an empty HEAD\n> but not multiple commits.\n>\n> Allow the multiple commit case, too.\n>\n> Reported-by: Fabrizio Cucci <fabrizio.cucci@gmail.com>\n> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n> ---\n>  sequencer.c | 11 ++++++-----\n>  1 file changed, 6 insertions(+), 5 deletions(-)\n\nThanks; we'd probably want a few tests in somewhere near 3503 or\n3505.\n\n> diff --git a/sequencer.c b/sequencer.c\n> index 4687ad4..c6362d6 100644\n> --- a/sequencer.c\n> +++ b/sequencer.c\n> @@ -888,6 +888,10 @@ static int sequencer_rollback(struct replay_opts *opts)\n>  \t\t\tgit_path_head_file());\n>  \t\tgoto fail;\n>  \t}\n> +\tif (is_null_sha1(sha1)) {\n> +\t\terror(_(\"cannot abort from a branch yet to be born\"));\n> +\t\tgoto fail;\n> +\t}\n\nIs this error-fail desirable?  How do we get here?  Did a user start\na cherry-pick on an unborn branch and then told us to abort that?\nShouldn't we be taking the user back to the \"orphan\" state if that\nis the case?\n\n>  \tif (reset_for_rollback(sha1))\n>  \t\tgoto fail;\n>  \tremove_sequencer_state();\n> @@ -1086,11 +1090,8 @@ int sequencer_pick_revisions(struct replay_opts *opts)\n>  \twalk_revs_populate_todo(&todo_list, opts);\n>  \tif (create_seq_dir() < 0)\n>  \t\treturn -1;\n> -\tif (get_sha1(\"HEAD\", sha1)) {\n> -\t\tif (opts->action == REPLAY_REVERT)\n> -\t\t\treturn error(_(\"Can't revert as initial commit\"));\n> -\t\treturn error(_(\"Can't cherry-pick into empty head\"));\n> -\t}\n> +\tif (get_sha1(\"HEAD\", sha1) && (opts->action == REPLAY_REVERT))\n> +\t\treturn error(_(\"Can't revert as initial commit\"));\n\nNot a new issue, but I cannot quite fathom what this error message\nwants to say.  \"Can't revert an initial commit\"?\n\n>  \tsave_head(sha1_to_hex(sha1));\n>  \tsave_opts(opts);\n>  \treturn pick_commits(todo_list, opts);\n"},{"id":"288523","messageId":"88c61a4d-abee-2c01-a521-8094b4baf3ac@drmicha.warpmail.net","threadId":"42477","inReplyTo":"xmqq7fe2w087.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] cherry-pick: allow to pick to unborn branches","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2016-06-07T06:37:25Z","receivedAt":"2016-06-07T06:37:25Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 06.06.2016 22:06:\n> Michael J Gruber <git@drmicha.warpmail.net> writes:\n> \n>> Currently, cherry-pick allows tp pick single commits to an empty HEAD\n>> but not multiple commits.\n>>\n>> Allow the multiple commit case, too.\n>>\n>> Reported-by: Fabrizio Cucci <fabrizio.cucci@gmail.com>\n>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n>> ---\n>>  sequencer.c | 11 ++++++-----\n>>  1 file changed, 6 insertions(+), 5 deletions(-)\n> \n> Thanks; we'd probably want a few tests in somewhere near 3503 or\n> 3505.\n\nI'll try my best.\n\n>> diff --git a/sequencer.c b/sequencer.c\n>> index 4687ad4..c6362d6 100644\n>> --- a/sequencer.c\n>> +++ b/sequencer.c\n>> @@ -888,6 +888,10 @@ static int sequencer_rollback(struct replay_opts *opts)\n>>  \t\t\tgit_path_head_file());\n>>  \t\tgoto fail;\n>>  \t}\n>> +\tif (is_null_sha1(sha1)) {\n>> +\t\terror(_(\"cannot abort from a branch yet to be born\"));\n>> +\t\tgoto fail;\n>> +\t}\n> \n> Is this error-fail desirable?  How do we get here?  Did a user start\n> a cherry-pick on an unborn branch and then told us to abort that?\n> Shouldn't we be taking the user back to the \"orphan\" state if that\n> is the case?\n\nHere and below, I'm mimicking/copying the behavior that we have right\nnow already. I asked myself the same question - rolling back to orphan\nstate shouldn't be that hard after all. But that would be a change in\nbehavior that - if considered a fix/improvement - would be orthogonal to\nthe multi-pick fix.\n\n>>  \tif (reset_for_rollback(sha1))\n>>  \t\tgoto fail;\n>>  \tremove_sequencer_state();\n>> @@ -1086,11 +1090,8 @@ int sequencer_pick_revisions(struct replay_opts *opts)\n>>  \twalk_revs_populate_todo(&todo_list, opts);\n>>  \tif (create_seq_dir() < 0)\n>>  \t\treturn -1;\n>> -\tif (get_sha1(\"HEAD\", sha1)) {\n>> -\t\tif (opts->action == REPLAY_REVERT)\n>> -\t\t\treturn error(_(\"Can't revert as initial commit\"));\n>> -\t\treturn error(_(\"Can't cherry-pick into empty head\"));\n>> -\t}\n>> +\tif (get_sha1(\"HEAD\", sha1) && (opts->action == REPLAY_REVERT))\n>> +\t\treturn error(_(\"Can't revert as initial commit\"));\n> \n> Not a new issue, but I cannot quite fathom what this error message\n> wants to say.  \"Can't revert an initial commit\"?\n\nCannot create a \"revert commit\" as the initial commit on a yet unborn\nbranch. Maybe \"nothing to revert\" would be clearer, but then another\nuser might ask: If I say \"git revert deabeef\" and there is a commit\n\"deadbeef\" then why is there \"nothing to revert\"?\n\nApplying the reverse of a patch to an empty tree should result in an\nempty tree, and creating a commit with that empty tree as \"This reverts\ncommit deadbeef\" is what we are refusing here, unless I'm confused.\n\n>>  \tsave_head(sha1_to_hex(sha1));\n>>  \tsave_opts(opts);\n>>  \treturn pick_commits(todo_list, opts);\n> \n"},{"id":"288528","messageId":"xmqqoa7dscov.fsf@gitster.mtv.corp.google.com","threadId":"42477","inReplyTo":"88c61a4d-abee-2c01-a521-8094b4baf3ac@drmicha.warpmail.net","subject":"Re: [PATCH] cherry-pick: allow to pick to unborn branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-06-07T07:03:28Z","receivedAt":"2016-06-07T07:03:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n> Here and below, I'm mimicking/copying the behavior that we have right\n> now already. I asked myself the same question - rolling back to orphan\n> state shouldn't be that hard after all. But that would be a change in\n> behavior that - if considered a fix/improvement - would be orthogonal to\n> the multi-pick fix.\n\nHmph, OK.\n\n>>> @@ -1086,11 +1090,8 @@ int sequencer_pick_revisions(struct replay_opts *opts)\n>>>  \twalk_revs_populate_todo(&todo_list, opts);\n>>>  \tif (create_seq_dir() < 0)\n>>>  \t\treturn -1;\n>>> -\tif (get_sha1(\"HEAD\", sha1)) {\n>>> -\t\tif (opts->action == REPLAY_REVERT)\n>>> -\t\t\treturn error(_(\"Can't revert as initial commit\"));\n>>> -\t\treturn error(_(\"Can't cherry-pick into empty head\"));\n>>> -\t}\n>>> +\tif (get_sha1(\"HEAD\", sha1) && (opts->action == REPLAY_REVERT))\n>>> +\t\treturn error(_(\"Can't revert as initial commit\"));\n>> \n>> Not a new issue, but I cannot quite fathom what this error message\n>> wants to say.  \"Can't revert an initial commit\"?\n>\n> Cannot create a \"revert commit\" as the initial commit on a yet unborn\n> branch. Maybe \"nothing to revert\" would be clearer, but then another\n> user might ask: If I say \"git revert deabeef\" and there is a commit\n> \"deadbeef\" then why is there \"nothing to revert\"?\n>\n> Applying the reverse of a patch to an empty tree should result in an\n> empty tree, and creating a commit with that empty tree as \"This reverts\n> commit deadbeef\" is what we are refusing here, unless I'm confused.\n\nOK, so the message wants to say \"a revert cannot be recorded as\ninitial commit\" (because the original change has to be one that\nresults in an empty tree to be able to sanely be reversed its effect\non top of an empty tree)?  That interpretation is understandable.\n\nBut that still sounds like a fishy logic.\n\nA root commit should be cherry-pickable as it is a change to\nwhatever state from an empty tree, and we do allow it.  The same\nreasoning suggests that if you find a change that makes the tree\nempty, such a change should be revert-able on top of an empty tree.\n\nIn fact, we do allow cherry-picking a non-root commit onto an empty\ntree, as long as the changes are all about creating new files.  So\nperhaps a change that only removes files should be revert-able on\ntop of an empty tree?\n\nIn any case, this topic is not about fixing that semantics of the\nrevert and it is a tangent.  I'll just leave the usual \"low hanging fruit\"\nmark so that people can list-archive-search for that string to find\nit as a possible mini-project to allow reverting such a change on top\nof an empty tree.\n\nThanks.\n"}]}