On Thu, Oct 5, 2017 at 12:13 PM, Johannes Sixt <j6t@xxxxxxxx> wrote: > Add a new command that can be used to copy an arbitrary commit > to a branch that is not checked out. Cool. :) > > Signed-off-by: Johannes Sixt <j6t@xxxxxxxx> > --- > 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?) > + > +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. > + > +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.
