Am 05.10.2017 um 21:33 schrieb Stefan Beller:
On Thu, Oct 5, 2017 at 12:13 PM, Johannes Sixt <j6t@xxxxxxxx> wrote:
+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?
Maybe. Maybe "cherry picking" is sufficiently clear that it is not needed.
* Is it a good design choice to have a different command, just because the
target branch is [not] checked out?
I would not want to make it a sub-mode of cherry-pick, if that is what
you mean, because "cherry picking" is about getting something, not
giving something away.
* Naming: I just searched for synonyms "opposite of cherry-picking" and
came up with cherry-put, cherry-post, target-commit
With command line completion, we have to type 'git cherr<TAB>-<TAB>'
currently. If we add another command that begins with 'cherry-', another
<TAB> is needed. Therefore, I do not want to use a name starting with
'cherry-'.
* What was the rationale for naming it "post" (it sounds very generic to me)?
Yes, it is generic, but I did not find a better word that means "give
away" a commit. Perhaps "tack"?
* Does it play well with worktrees? (i.e. if a worktree has a branch checked
out, we cannot post there, or can we?)
Good point. It should be forbidden, but there are no safety checks,
currently.
+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.
Thanks. Another use case is when you receive a patch to be applied on a
different branch while you are in the middle of some work. If it can be
applied on the current branch, then you can post it to the destination,
rewind, and continue with your work.
+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.
Oh, it does so return an error. But there are some cases that one
expects that work, but where git-apply is not capable enough.
-- Hannes
