Re: [PATCH/RFC] git-post: the opposite of git-cherry-pick

From: Stefan Beller <sbeller@google.com>
Date: Oct 5, 2017, 19:33 UTC
Message-ID: <CAGZ79kbr=zBc5GEL7hYyCnBcbdE8ZRp65QwxKMUVsQ+qXvRAAw@mail.gmail.com>
In-Reply-To: <c6b52120-98bf-d685-6dc0-3c83e9e80d30@kdbg.org>

On Thu, Oct 5, 2017 at 12:13 PM, Johannes Sixt <j6t@kdbg.org> wrote:

> Add a new command that can be used to copy an arbitrary commit
> to a branch that is not checked out.

Cool. :)

Show 58 quoted lines

>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
>  I have been using this command since years, but got around to
>  write a man page and tests only now. I hope the man page makes
>  sense. I don't have the tool chain to build it, though, so
>  any hints for improvement are welcome.
>
>  .gitignore                        |  1 +
>  Documentation/git-cherry-pick.txt |  3 +-
>  Documentation/git-post.txt        | 57 +++++++++++++++++++++++++++++
>  Makefile                          |  1 +
>  command-list.txt                  |  1 +
>  git-post.sh                       | 60 ++++++++++++++++++++++++++++++
>  t/t3514-post.sh                   | 77 +++++++++++++++++++++++++++++++++++++++
>  7 files changed, 199 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/git-post.txt
>  create mode 100755 git-post.sh
>  create mode 100755 t/t3514-post.sh
>
> diff --git a/.gitignore b/.gitignore
> index 833ef3b0b7..a16263249a 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -106,6 +106,7 @@
>  /git-pack-refs
>  /git-parse-remote
>  /git-patch-id
> +/git-post
>  /git-prune
>  /git-prune-packed
>  /git-pull
> diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
> index d35d771fc8..6b34f4d994 100644
> --- a/Documentation/git-cherry-pick.txt
> +++ b/Documentation/git-cherry-pick.txt
> @@ -226,7 +226,8 @@ context lines.
>
>  SEE ALSO
>  --------
> -linkgit:git-revert[1]
> +linkgit:git-revert[1],
> +linkgit:git-post[1]
>
>  GIT
>  ---
> diff --git a/Documentation/git-post.txt b/Documentation/git-post.txt
> new file mode 100644
> index 0000000000..e835e62be3
> --- /dev/null
> +++ b/Documentation/git-post.txt
> @@ -0,0 +1,57 @@
> +git-post(1)
> +===========
> +
> +NAME
> +----
> +git-post - Apply a commit on top of a branch that is not checked out

Contrasted to:
  git-cherry-pick - Apply the changes introduced by some existing commits
Some questions on top of my head:
* Do we want to emphasize the cherry-pick to say checked out?
* Is it a good design choice to have a different command, just because the
  target branch is [not] checked out?
* Naming: I just searched for synonyms "opposite of cherry-picking" and
  came up with cherry-put, cherry-post, target-commit
* What was the rationale for naming it "post" (it sounds very generic to me)?
* Does it play well with worktrees? (i.e. if a worktree has a branch checked
  out, we cannot post there, or can we?)

Show 37 quoted lines

> +
> +SYNOPSIS
> +--------
> +[verse]
> +'git post' dest-branch [source-rev]
> +
> +DESCRIPTION
> +-----------
> +
> +Applies the changes made by 'source-rev' (or, if not given, `HEAD`)
> +on top of the branch 'dest-branch' and records a new commit.
> +'dest-branch' is advanced to point to the new commit.
> +The operation that this command performs can be regarded as
> +the opposite of cherry-picking.
> +
> +EXAMPLES
> +--------
> +
> +Assume, while working on a topic, you find and fix an unrelated bug.
> +Now:
> +
> +------------
> +$ git commit                                   <1>
> +$ git post master                              <2>
> +$ git show | git apply -R && git reset HEAD^   <3>
> +------------
> +
> +<1> create a commit with the fix on the current branch
> +<2> copy the fix onto the branch where it ought to be
> +<3> revert current topic branch to the unfixed state;
> +can also be done with `git reset --keep HEAD^` if there are no
> +unstaged changes in files that are modified by the fix
> +
> +Oftentimes, switching branches triggers a rebuild of a code base.
> +With the sequence above the branch switch can be avoided.
> +That said, it is good practice to test the bug fix on the
> +destination branch eventually.

This is a cool and motivating example.

Show 6 quoted lines

> +
> +BUGS
> +----
> +
> +The change can be applied on `dest-branch` only if there is
> +no textual conflict.

This is not a bug per se, it could be signaled via a return code that the posting was unsuccessful.