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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux