{"thread":{"id":"46914","subject":"[PATCH/RFC] git-post: the opposite of git-cherry-pick","startedAt":"2017-10-05T19:13:38Z","lastAt":"2017-10-17T21:15:40Z","messageCount":8,"participants":["Johannes Sixt","Stefan Beller","Ævar Arnfjörð Bjarmason","Rafael Ascensao","Igor Djordjevic"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"329777","messageId":"c6b52120-98bf-d685-6dc0-3c83e9e80d30@kdbg.org","threadId":"46914","inReplyTo":null,"subject":"[PATCH/RFC] git-post: the opposite of git-cherry-pick","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2017-10-05T19:13:29Z","receivedAt":"2017-10-05T19:13:38Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Add a new command that can be used to copy an arbitrary commit\nto a branch that is not checked out.\n\nSigned-off-by: Johannes Sixt <j6t@kdbg.org>\n---\n I have been using this command since years, but got around to\n write a man page and tests only now. I hope the man page makes\n sense. I don't have the tool chain to build it, though, so\n any hints for improvement are welcome.\n\n .gitignore                        |  1 +\n Documentation/git-cherry-pick.txt |  3 +-\n Documentation/git-post.txt        | 57 +++++++++++++++++++++++++++++\n Makefile                          |  1 +\n command-list.txt                  |  1 +\n git-post.sh                       | 60 ++++++++++++++++++++++++++++++\n t/t3514-post.sh                   | 77 +++++++++++++++++++++++++++++++++++++++\n 7 files changed, 199 insertions(+), 1 deletion(-)\n create mode 100644 Documentation/git-post.txt\n create mode 100755 git-post.sh\n create mode 100755 t/t3514-post.sh\n\ndiff --git a/.gitignore b/.gitignore\nindex 833ef3b0b7..a16263249a 100644\n--- a/.gitignore\n+++ b/.gitignore\n@@ -106,6 +106,7 @@\n /git-pack-refs\n /git-parse-remote\n /git-patch-id\n+/git-post\n /git-prune\n /git-prune-packed\n /git-pull\ndiff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt\nindex d35d771fc8..6b34f4d994 100644\n--- a/Documentation/git-cherry-pick.txt\n+++ b/Documentation/git-cherry-pick.txt\n@@ -226,7 +226,8 @@ context lines.\n \n SEE ALSO\n --------\n-linkgit:git-revert[1]\n+linkgit:git-revert[1],\n+linkgit:git-post[1]\n \n GIT\n ---\ndiff --git a/Documentation/git-post.txt b/Documentation/git-post.txt\nnew file mode 100644\nindex 0000000000..e835e62be3\n--- /dev/null\n+++ b/Documentation/git-post.txt\n@@ -0,0 +1,57 @@\n+git-post(1)\n+===========\n+\n+NAME\n+----\n+git-post - Apply a commit on top of a branch that is not checked out\n+\n+SYNOPSIS\n+--------\n+[verse]\n+'git post' dest-branch [source-rev]\n+\n+DESCRIPTION\n+-----------\n+\n+Applies the changes made by 'source-rev' (or, if not given, `HEAD`)\n+on top of the branch 'dest-branch' and records a new commit.\n+'dest-branch' is advanced to point to the new commit.\n+The operation that this command performs can be regarded as\n+the opposite of cherry-picking.\n+\n+EXAMPLES\n+--------\n+\n+Assume, while working on a topic, you find and fix an unrelated bug.\n+Now:\n+\n+------------\n+$ git commit                                   <1>\n+$ git post master                              <2>\n+$ git show | git apply -R && git reset HEAD^   <3>\n+------------\n+\n+<1> create a commit with the fix on the current branch\n+<2> copy the fix onto the branch where it ought to be\n+<3> revert current topic branch to the unfixed state;\n+can also be done with `git reset --keep HEAD^` if there are no\n+unstaged changes in files that are modified by the fix\n+\n+Oftentimes, switching branches triggers a rebuild of a code base.\n+With the sequence above the branch switch can be avoided.\n+That said, it is good practice to test the bug fix on the\n+destination branch eventually.\n+\n+BUGS\n+----\n+\n+The change can be applied on `dest-branch` only if there is\n+no textual conflict.\n+\n+SEE ALSO\n+--------\n+linkgit:git-cherry-pick[1].\n+\n+GIT\n+---\n+Part of the linkgit:git[1] suite\ndiff --git a/Makefile b/Makefile\nindex b143e4eea3..1753bf176f 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -551,6 +551,7 @@ SCRIPT_SH += git-merge-octopus.sh\n SCRIPT_SH += git-merge-one-file.sh\n SCRIPT_SH += git-merge-resolve.sh\n SCRIPT_SH += git-mergetool.sh\n+SCRIPT_SH += git-post.sh\n SCRIPT_SH += git-quiltimport.sh\n SCRIPT_SH += git-rebase.sh\n SCRIPT_SH += git-remote-testgit.sh\ndiff --git a/command-list.txt b/command-list.txt\nindex a1fad28fd8..bc95b424d0 100644\n--- a/command-list.txt\n+++ b/command-list.txt\n@@ -98,6 +98,7 @@ git-pack-redundant                      plumbinginterrogators\n git-pack-refs                           ancillarymanipulators\n git-parse-remote                        synchelpers\n git-patch-id                            purehelpers\n+git-post                                mainporcelain\n git-prune                               ancillarymanipulators\n git-prune-packed                        plumbingmanipulators\n git-pull                                mainporcelain           remote\ndiff --git a/git-post.sh b/git-post.sh\nnew file mode 100755\nindex 0000000000..6627d69f73\n--- /dev/null\n+++ b/git-post.sh\n@@ -0,0 +1,60 @@\n+#!/bin/sh\n+# Copyright (c) 2017 Johannes Sixt\n+\n+SUBDIRECTORY_OK=Yes\n+OPTIONS_SPEC=\"\\\n+git post dest-branch [source-rev]\n+--\n+\"\n+. git-sh-setup\n+\n+while test $# != 0\n+do\n+\tcase \"$1\" in\n+\t--)\tshift; break;;\n+\t-*)\tusage;;\n+\t*)\tbreak;;\n+\tesac\n+\tshift\n+done\n+\n+dest=$(git rev-parse --verify --symbolic-full-name \"$1\") || exit\n+if test -z \"$dest\"\n+then\n+\tdie \"$(gettext \"Destination must be a branch tip\")\"\n+fi\n+\n+shift\n+case $# in\n+0)\tset -- HEAD;;\n+1)\t: good;;\n+*)\tusage;;\n+esac\n+\n+# apply change to a temporary index\n+tmpidx=$GIT_DIR/index-post-$$\n+git read-tree --index-output=\"$tmpidx\" \"$dest\" || exit\n+GIT_INDEX_FILE=$tmpidx\n+export GIT_INDEX_FILE\n+trap 'rm -f \"$tmpidx\"' 0 1 2 15\n+\n+git diff-tree -p --binary -M -C \"$1\" | git apply --cached || exit\n+\n+newtree=$(git write-tree) &&\n+newrev=$(\n+\teval \"$(get_author_ident_from_commit \"$1\")\" &&\n+\texport GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE\n+\tgit-cat-file commit \"$1\" | sed -e '1,/^$/d' |\n+\tgit commit-tree $newtree -p \"$dest\"\n+) || exit\n+\n+if git check-ref-format \"$dest\"\n+then\n+\tset_reflog_action post\n+\tsubject=$(git log --no-walk --pretty=%s \"$newrev\") &&\n+\tgit update-ref -m \"$GIT_REFLOG_ACTION: $subject\" \"$dest\" \"$newrev\" || exit\n+fi\n+if test -z \"$GIT_QUIET\"\n+then\n+\tgit rev-list -1 --oneline \"$newrev\"\n+fi\ndiff --git a/t/t3514-post.sh b/t/t3514-post.sh\nnew file mode 100755\nindex 0000000000..4d31515c52\n--- /dev/null\n+++ b/t/t3514-post.sh\n@@ -0,0 +1,77 @@\n+#!/bin/sh\n+\n+test_description='test git post\n+\n+We build this history:\n+\n+   A--B--C  <-- master, HEAD\n+  /\n+ O          <-- side-base, side\n+\n+Then we post B and C on top of branch \"side\":\n+\n+   A--B--C  <-- master, HEAD\n+  /\n+ O          <-- side-base\n+  \\\n+   B*--C*   <-- side\n+\n+B has a different author, which must be copied to B*.\n+'\n+\n+. ./test-lib.sh\n+\n+test_expect_success setup '\n+\n+\tprintf \"a%s\\n\" 1 2 3 4 >file-a &&\n+\tprintf \"b%s\\n\" 5 6 7 8 >file-b &&\n+\n+\ttest_tick &&\n+\tgit add file-a file-b &&\n+\tgit commit -m initial &&\n+\tgit tag side-base &&\n+\n+\ttest_tick &&\n+\techo \"Advance master\" >>file-a &&\n+\tgit commit -a -m advance-master &&\n+\n+\ttest_tick &&\n+\techo \"Unrelated fix\" >>file-b &&\n+\tGIT_AUTHOR_NAME=\"S O Else\" git commit -a -m fix-for-b &&\n+\n+\ttest_tick &&\n+\techo \"Another fix\" >>file-b &&\n+\tgit commit -a -m another-fix-for-b\n+'\n+\n+test_expect_success 'post two commits on top of side' '\n+\n+\tgit branch -f side side-base &&\n+\ttest_tick &&\n+\tgit post side HEAD^ &&\n+\ttest_tick &&\n+\tgit post side &&\n+\n+\tgit log --pretty=\"%at %an %ae %s\" HEAD~2.. >expect &&\n+\tgit log --pretty=\"%at %an %ae %s\" side-base..side >actual &&\n+\n+\ttest_cmp expect actual &&\n+\tgit cat-file blob side:file-b >actual &&\n+\ttest_cmp file-b actual &&\n+\n+\tgit diff --exit-code side-base side -- file-a\t# no change\n+'\n+\n+test_expect_success 'post requiring merge resolution fails' '\n+\n+\tgit branch -f side side-base &&\n+\ttest_must_fail git post side HEAD\n+'\n+\n+test_expect_success 'cannot post onto arbitrary commit name' '\n+\n+\tgit branch -f side side-base &&\n+\ttest_must_fail git post side^0 HEAD^\n+'\n+\n+test_done\n-- \n2.14.2.808.g3bc32f2729\n"},{"id":"329778","messageId":"CAGZ79kbr=zBc5GEL7hYyCnBcbdE8ZRp65QwxKMUVsQ+qXvRAAw@mail.gmail.com","threadId":"46914","inReplyTo":"c6b52120-98bf-d685-6dc0-3c83e9e80d30@kdbg.org","subject":"Re: [PATCH/RFC] git-post: the opposite of git-cherry-pick","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-10-05T19:33:38Z","receivedAt":"2017-10-05T19:33:46Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Oct 5, 2017 at 12:13 PM, Johannes Sixt <j6t@kdbg.org> wrote:\n> Add a new command that can be used to copy an arbitrary commit\n> to a branch that is not checked out.\n\nCool. :)\n\n>\n> Signed-off-by: Johannes Sixt <j6t@kdbg.org>\n> ---\n>  I have been using this command since years, but got around to\n>  write a man page and tests only now. I hope the man page makes\n>  sense. I don't have the tool chain to build it, though, so\n>  any hints for improvement are welcome.\n>\n>  .gitignore                        |  1 +\n>  Documentation/git-cherry-pick.txt |  3 +-\n>  Documentation/git-post.txt        | 57 +++++++++++++++++++++++++++++\n>  Makefile                          |  1 +\n>  command-list.txt                  |  1 +\n>  git-post.sh                       | 60 ++++++++++++++++++++++++++++++\n>  t/t3514-post.sh                   | 77 +++++++++++++++++++++++++++++++++++++++\n>  7 files changed, 199 insertions(+), 1 deletion(-)\n>  create mode 100644 Documentation/git-post.txt\n>  create mode 100755 git-post.sh\n>  create mode 100755 t/t3514-post.sh\n>\n> diff --git a/.gitignore b/.gitignore\n> index 833ef3b0b7..a16263249a 100644\n> --- a/.gitignore\n> +++ b/.gitignore\n> @@ -106,6 +106,7 @@\n>  /git-pack-refs\n>  /git-parse-remote\n>  /git-patch-id\n> +/git-post\n>  /git-prune\n>  /git-prune-packed\n>  /git-pull\n> diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt\n> index d35d771fc8..6b34f4d994 100644\n> --- a/Documentation/git-cherry-pick.txt\n> +++ b/Documentation/git-cherry-pick.txt\n> @@ -226,7 +226,8 @@ context lines.\n>\n>  SEE ALSO\n>  --------\n> -linkgit:git-revert[1]\n> +linkgit:git-revert[1],\n> +linkgit:git-post[1]\n>\n>  GIT\n>  ---\n> diff --git a/Documentation/git-post.txt b/Documentation/git-post.txt\n> new file mode 100644\n> index 0000000000..e835e62be3\n> --- /dev/null\n> +++ b/Documentation/git-post.txt\n> @@ -0,0 +1,57 @@\n> +git-post(1)\n> +===========\n> +\n> +NAME\n> +----\n> +git-post - Apply a commit on top of a branch that is not checked out\n\nContrasted to:\n  git-cherry-pick - Apply the changes introduced by some existing commits\nSome questions on top of my head:\n* Do we want to emphasize the cherry-pick to say checked out?\n* Is it a good design choice to have a different command, just because the\n  target branch is [not] checked out?\n* Naming: I just searched for synonyms \"opposite of cherry-picking\" and\n  came up with cherry-put, cherry-post, target-commit\n* What was the rationale for naming it \"post\" (it sounds very generic to me)?\n* Does it play well with worktrees? (i.e. if a worktree has a branch checked\n  out, we cannot post there, or can we?)\n\n> +\n> +SYNOPSIS\n> +--------\n> +[verse]\n> +'git post' dest-branch [source-rev]\n> +\n> +DESCRIPTION\n> +-----------\n> +\n> +Applies the changes made by 'source-rev' (or, if not given, `HEAD`)\n> +on top of the branch 'dest-branch' and records a new commit.\n> +'dest-branch' is advanced to point to the new commit.\n> +The operation that this command performs can be regarded as\n> +the opposite of cherry-picking.\n> +\n> +EXAMPLES\n> +--------\n> +\n> +Assume, while working on a topic, you find and fix an unrelated bug.\n> +Now:\n> +\n> +------------\n> +$ git commit                                   <1>\n> +$ git post master                              <2>\n> +$ git show | git apply -R && git reset HEAD^   <3>\n> +------------\n> +\n> +<1> create a commit with the fix on the current branch\n> +<2> copy the fix onto the branch where it ought to be\n> +<3> revert current topic branch to the unfixed state;\n> +can also be done with `git reset --keep HEAD^` if there are no\n> +unstaged changes in files that are modified by the fix\n> +\n> +Oftentimes, switching branches triggers a rebuild of a code base.\n> +With the sequence above the branch switch can be avoided.\n> +That said, it is good practice to test the bug fix on the\n> +destination branch eventually.\n\nThis is a cool and motivating example.\n\n\n> +\n> +BUGS\n> +----\n> +\n> +The change can be applied on `dest-branch` only if there is\n> +no textual conflict.\n\nThis is not a bug per se, it could be signaled via a return code that\nthe posting was unsuccessful.\n"},{"id":"329812","messageId":"3d362037-3eb6-83db-a17f-47a984135580@kdbg.org","threadId":"46914","inReplyTo":"CAGZ79kbr=zBc5GEL7hYyCnBcbdE8ZRp65QwxKMUVsQ+qXvRAAw@mail.gmail.com","subject":"Re: [PATCH/RFC] git-post: the opposite of git-cherry-pick","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2017-10-05T21:22:01Z","receivedAt":"2017-10-05T21:22:09Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 05.10.2017 um 21:33 schrieb Stefan Beller:\n> On Thu, Oct 5, 2017 at 12:13 PM, Johannes Sixt <j6t@kdbg.org> wrote:\n>> +git-post(1)\n>> +===========\n>> +\n>> +NAME\n>> +----\n>> +git-post - Apply a commit on top of a branch that is not checked out\n> \n> Contrasted to:\n>    git-cherry-pick - Apply the changes introduced by some existing commits\n> Some questions on top of my head:\n> * Do we want to emphasize the cherry-pick to say checked out?\n\nMaybe. Maybe \"cherry picking\" is sufficiently clear that it is not needed.\n\n> * Is it a good design choice to have a different command, just because the\n>    target branch is [not] checked out?\n\nI would not want to make it a sub-mode of cherry-pick, if that is what \nyou mean, because \"cherry picking\" is about getting something, not \ngiving something away.\n\n> * Naming: I just searched for synonyms \"opposite of cherry-picking\" and\n>    came up with cherry-put, cherry-post, target-commit\n\nWith command line completion, we have to type 'git cherr<TAB>-<TAB>' \ncurrently. If we add another command that begins with 'cherry-', another \n<TAB> is needed. Therefore, I do not want to use a name starting with \n'cherry-'.\n\n> * What was the rationale for naming it \"post\" (it sounds very generic to me)?\n\nYes, it is generic, but I did not find a better word that means \"give \naway\" a commit. Perhaps \"tack\"?\n\n> * Does it play well with worktrees? (i.e. if a worktree has a branch checked\n>    out, we cannot post there, or can we?)\n\nGood point. It should be forbidden, but there are no safety checks, \ncurrently.\n\n>> +EXAMPLES\n>> +--------\n>> +\n>> +Assume, while working on a topic, you find and fix an unrelated bug.\n>> +Now:\n>> +\n>> +------------\n>> +$ git commit                                   <1>\n>> +$ git post master                              <2>\n>> +$ git show | git apply -R && git reset HEAD^   <3>\n>> +------------\n>> +\n>> +<1> create a commit with the fix on the current branch\n>> +<2> copy the fix onto the branch where it ought to be\n>> +<3> revert current topic branch to the unfixed state;\n>> +can also be done with `git reset --keep HEAD^` if there are no\n>> +unstaged changes in files that are modified by the fix\n>> +\n>> +Oftentimes, switching branches triggers a rebuild of a code base.\n>> +With the sequence above the branch switch can be avoided.\n>> +That said, it is good practice to test the bug fix on the\n>> +destination branch eventually.\n> \n> This is a cool and motivating example.\n\nThanks. Another use case is when you receive a patch to be applied on a \ndifferent branch while you are in the middle of some work. If it can be \napplied on the current branch, then you can post it to the destination, \nrewind, and continue with your work.\n\n>> +BUGS\n>> +----\n>> +\n>> +The change can be applied on `dest-branch` only if there is\n>> +no textual conflict.\n> \n> This is not a bug per se, it could be signaled via a return code that\n> the posting was unsuccessful.\n\nOh, it does so return an error. But there are some cases that one \nexpects that work, but where git-apply is not capable enough.\n\n-- Hannes\n"},{"id":"330346","messageId":"87wp3zs4la.fsf@evledraar.booking.com","threadId":"46914","inReplyTo":"3d362037-3eb6-83db-a17f-47a984135580@kdbg.org","subject":"Re: [PATCH/RFC] git-post: the opposite of git-cherry-pick","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-10-13T10:51:45Z","receivedAt":"2017-10-13T10:51:53Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Oct 05 2017, Johannes Sixt jotted:\n\n> Am 05.10.2017 um 21:33 schrieb Stefan Beller:\n>> On Thu, Oct 5, 2017 at 12:13 PM, Johannes Sixt <j6t@kdbg.org> wrote:\n>>> +git-post(1)\n>>> +===========\n>>> +\n>>> +NAME\n>>> +----\n>>> +git-post - Apply a commit on top of a branch that is not checked out\n\nIt would be great to have this somehow, whatever the UI ends up being.\n\n>> Contrasted to:\n>>    git-cherry-pick - Apply the changes introduced by some existing commits\n>> Some questions on top of my head:\n>> * Do we want to emphasize the cherry-pick to say checked out?\n>\n> Maybe. Maybe \"cherry picking\" is sufficiently clear that it is not needed.\n>\n>> * Is it a good design choice to have a different command, just because the\n>>    target branch is [not] checked out?\n>\n> I would not want to make it a sub-mode of cherry-pick, if that is what\n> you mean, because \"cherry picking\" is about getting something, not\n> giving something away.\n\nIt occurs to me that a better long-term UI design might be to make\ngit-{cherry-pick,pick) some sort of submodes for git-commit.\n\nRight now git-commit picks the current index for committing, but \"use a\npatch as the source instead\" could be a submode.\n\nRight now it commits that change on top of your checked out commit, but\n\"other non-checked-out target commit\" could be a mode instead,\ni.e. exposing more of the power of the underlying git-commit-tree.\n\nJust food for thought.\n\n>> * Naming: I just searched for synonyms \"opposite of cherry-picking\" and\n>>    came up with cherry-put, cherry-post, target-commit\n>\n> With command line completion, we have to type 'git cherr<TAB>-<TAB>'\n> currently. If we add another command that begins with 'cherry-',\n> another <TAB> is needed. Therefore, I do not want to use a name\n> starting with 'cherry-'.\n>\n>> * What was the rationale for naming it \"post\" (it sounds very generic to me)?\n>\n> Yes, it is generic, but I did not find a better word that means \"give\n> away\" a commit. Perhaps \"tack\"?\n\n[Not entirely serious]. Well if cherry-picking is taking a thing and\neating it here, maybe git-cherry-puke takes an already digested thing\nand \"throws\" it elsewhere ?:)\n\nIt's a silly name but it's somewhat symmetric :)\n\n>> * Does it play well with worktrees? (i.e. if a worktree has a branch checked\n>>    out, we cannot post there, or can we?)\n>\n> Good point. It should be forbidden, but there are no safety checks,\n> currently.\n>\n>>> +EXAMPLES\n>>> +--------\n>>> +\n>>> +Assume, while working on a topic, you find and fix an unrelated bug.\n>>> +Now:\n>>> +\n>>> +------------\n>>> +$ git commit                                   <1>\n>>> +$ git post master                              <2>\n>>> +$ git show | git apply -R && git reset HEAD^   <3>\n>>> +------------\n>>> +\n>>> +<1> create a commit with the fix on the current branch\n>>> +<2> copy the fix onto the branch where it ought to be\n>>> +<3> revert current topic branch to the unfixed state;\n>>> +can also be done with `git reset --keep HEAD^` if there are no\n>>> +unstaged changes in files that are modified by the fix\n>>> +\n>>> +Oftentimes, switching branches triggers a rebuild of a code base.\n>>> +With the sequence above the branch switch can be avoided.\n>>> +That said, it is good practice to test the bug fix on the\n>>> +destination branch eventually.\n>>\n>> This is a cool and motivating example.\n>\n> Thanks. Another use case is when you receive a patch to be applied on\n> a different branch while you are in the middle of some work. If it can\n> be applied on the current branch, then you can post it to the\n> destination, rewind, and continue with your work.\n>\n>>> +BUGS\n>>> +----\n>>> +\n>>> +The change can be applied on `dest-branch` only if there is\n>>> +no textual conflict.\n>>\n>> This is not a bug per se, it could be signaled via a return code that\n>> the posting was unsuccessful.\n>\n> Oh, it does so return an error. But there are some cases that one\n> expects that work, but where git-apply is not capable enough.\n>\n> -- Hannes\n"},{"id":"330400","messageId":"33f7d379-126d-e27e-7dbf-616f5dfbc98a@kdbg.org","threadId":"46914","inReplyTo":"87wp3zs4la.fsf@evledraar.booking.com","subject":"Re: [PATCH/RFC] git-post: the opposite of git-cherry-pick","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2017-10-15T15:09:32Z","receivedAt":"2017-10-15T15:09:41Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 13.10.2017 um 12:51 schrieb Ævar Arnfjörð Bjarmason:\n> On Thu, Oct 05 2017, Johannes Sixt jotted:\n>> Am 05.10.2017 um 21:33 schrieb Stefan Beller:\n>>> * Is it a good design choice to have a different command, just because the\n>>>     target branch is [not] checked out?\n>>\n>> I would not want to make it a sub-mode of cherry-pick, if that is what\n>> you mean, because \"cherry picking\" is about getting something, not\n>> giving something away.\n> \n> It occurs to me that a better long-term UI design might be to make\n> git-{cherry-pick,pick) some sort of submodes for git-commit.\n\nI don't quite agree. To commit an index state that is derived from a \nworktree state is such a common and important operation that it deserves \nto be its own command. Adding different modi operandi would make it \nconfusing.\n\n> Right now git-commit picks the current index for committing, but \"use a\n> patch as the source instead\" could be a submode.\n> \n> Right now it commits that change on top of your checked out commit, but\n> \"other non-checked-out target commit\" could be a mode instead,\n> i.e. exposing more of the power of the underlying git-commit-tree.\n\nThis is worth discussing, though not my preference. The picture to \"pick \ncherries\" has become quite common, and now that we use it for the name \nof the command, \"cherry-pick\", the direction of flow is quite obvious \nand strongly implied: from somewhere else to me (and not to somebody else).\n\n> [Not entirely serious]. Well if cherry-picking is taking a thing and\n> eating it here, maybe git-cherry-puke takes an already digested thing\n> and \"throws\" it elsewhere ?:)\n> \n> It's a silly name but it's somewhat symmetric :)\n\nOne of the decisions to be made is whether to begin the new command with \n\"git-cherry-\" or not, because it introduces a new abiguity for command \nline completion.\n\n-- Hannes\n"},{"id":"330491","messageId":"CACUQV593kzMrtc4ENgD=6bBQcn0DXGRcyB7teCvGWk_QNtS98Q@mail.gmail.com","threadId":"46914","inReplyTo":"33f7d379-126d-e27e-7dbf-616f5dfbc98a@kdbg.org","subject":"Re: [PATCH/RFC] git-post: the opposite of git-cherry-pick","fromName":"Rafael Ascensao","fromEmail":"rafa.almas@gmail.com","sentAt":"2017-10-16T23:01:49Z","receivedAt":"2017-10-16T23:02:38Z","isPatch":true,"sender":{"key":"rafa.almas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1923789?v=4"},"body":"> This is worth discussing, though not my preference. The picture to \"pick\n> cherries\" has become quite common, and now that we use it for the name of\n> the command, \"cherry-pick\", the direction of flow is quite obvious and\n> strongly implied: from somewhere else to me (and not to somebody else).\n\nWhat if we borrow '--onto' from rebase and make it cherry-pick --onto\n<destination>?\n\nThis would keep the \"pick cherries\" analogy, but add the \"they're not\nfor me\" intention.\nIt also carries a bit of the \"transplant\" meaning of rebase.\n\n-Rafael Ascensão\n"},{"id":"330555","messageId":"d3ccfb02-004a-bbc3-af33-967db280c940@kdbg.org","threadId":"46914","inReplyTo":"CACUQV593kzMrtc4ENgD=6bBQcn0DXGRcyB7teCvGWk_QNtS98Q@mail.gmail.com","subject":"Re: [PATCH/RFC] git-post: the opposite of git-cherry-pick","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2017-10-17T17:30:05Z","receivedAt":"2017-10-17T17:30:13Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 17.10.2017 um 01:01 schrieb Rafael Ascensao:\n>> This is worth discussing, though not my preference. The picture to \"pick\n>> cherries\" has become quite common, and now that we use it for the name of\n>> the command, \"cherry-pick\", the direction of flow is quite obvious and\n>> strongly implied: from somewhere else to me (and not to somebody else).\n> \n> What if we borrow '--onto' from rebase and make it cherry-pick --onto\n> <destination>?\n\nI actually like this. Although I would miss the convenience that the \nsource defaults to HEAD. Unless we make a special case for --onto, that \nis, of course.\n\n-- Hannes\n"},{"id":"330576","messageId":"dcddb20d-b838-0131-ea31-4ab7186dd088@gmail.com","threadId":"46914","inReplyTo":"d3ccfb02-004a-bbc3-af33-967db280c940@kdbg.org","subject":"Re: [PATCH/RFC] git-post: the opposite of git-cherry-pick","fromName":"Igor Djordjevic","fromEmail":"igor.d.djordjevic@gmail.com","sentAt":"2017-10-17T21:15:29Z","receivedAt":"2017-10-17T21:15:40Z","isPatch":true,"sender":{"key":"igor.d.djordjevic@gmail.com","avatar":null},"body":"On 17/10/2017 19:30, Johannes Sixt wrote:\n> Am 17.10.2017 um 01:01 schrieb Rafael Ascensao:\n>>> This is worth discussing, though not my preference. The picture to \"pick\n>>> cherries\" has become quite common, and now that we use it for the name of\n>>> the command, \"cherry-pick\", the direction of flow is quite obvious and\n>>> strongly implied: from somewhere else to me (and not to somebody else).\n>>\n>> What if we borrow '--onto' from rebase and make it cherry-pick --onto\n>> <destination>?\n> \n> I actually like this. Although I would miss the convenience that the \n> source defaults to HEAD. Unless we make a special case for --onto, \n> that is, of course.\n\nI second this.\n\nFrom my point of view, I would say that \"cherry-pick\" in general \nseems to just imply \"taking\" commits (picking \"cherries\"), where \ndirection flow is irrelevant, or at least not strongly implied. For \nme, it`s more \"from somewhere else to somebody else\", indeed.\n\nThe fact that it currently \"posts\" its picks \"to me\" (on top of \ncurrent HEAD) could very well be justified/explained as the most \nobvious case (at time of implementation, at least), where usually one \ndoes work \"here\" (HEAD), thus cares to have commits picked over \n\"here\" as well - but it doesn`t have to be a restriction, where other \ndestination besides HEAD could/should be allowed.\n\nAnyway, I`d say current behaviour without \"--onto\" should stay, \nindeed, where HEAD destination is implied if not otherwise specified \n(and that seems to align well with some other Git commands, too). \nAlso, in case \"--onto\" _is_ provided, maybe commit to be picked could \nbe allowed to be omitted, defaulting to HEAD again, but as source \nthis time.\n\nThat said, might be 'git commit' looks like a nice candidate for \nbeing taught this new trick as well (optionally commit to a revision \nother than HEAD, what Ævar already mentioned), following the same \nlogic... ;) It would even be a better (more straightforward) fit for \none of your previous examples:\n\n> Another use case is when you receive a patch to be applied on a \n> different branch while you are in the middle of some work. If it can be \n> applied on the current branch, then you can post it to the destination, \n> rewind, and continue with your work.\n\np.s. I`m very interested in this functionality, and more - I have a \nbeginner`s attempt in addressing a similar use-case this topic is \nconcerned with (symptomatically using a variation of \"--onto\" as well \n:P), hopefully I`ll sent out something soon, for the sake of \ndiscussion/opinion, at least :(\n\nRegards,\nBuga\n"}]}