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

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

[Johannes Sixt]

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

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
+
+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.
+
+BUGS
+----
+
+The change can be applied on `dest-branch` only if there is
+no textual conflict.
+
+SEE ALSO
+--------
+linkgit:git-cherry-pick[1].
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Makefile b/Makefile
index b143e4eea3..1753bf176f 100644
--- a/Makefile
+++ b/Makefile
@@ -551,6 +551,7 @@ SCRIPT_SH += git-merge-octopus.sh
 SCRIPT_SH += git-merge-one-file.sh
 SCRIPT_SH += git-merge-resolve.sh
 SCRIPT_SH += git-mergetool.sh
+SCRIPT_SH += git-post.sh
 SCRIPT_SH += git-quiltimport.sh
 SCRIPT_SH += git-rebase.sh
 SCRIPT_SH += git-remote-testgit.sh
diff --git a/command-list.txt b/command-list.txt
index a1fad28fd8..bc95b424d0 100644
--- a/command-list.txt
+++ b/command-list.txt
@@ -98,6 +98,7 @@ git-pack-redundant                      plumbinginterrogators
 git-pack-refs                           ancillarymanipulators
 git-parse-remote                        synchelpers
 git-patch-id                            purehelpers
+git-post                                mainporcelain
 git-prune                               ancillarymanipulators
 git-prune-packed                        plumbingmanipulators
 git-pull                                mainporcelain           remote
diff --git a/git-post.sh b/git-post.sh
new file mode 100755
index 0000000000..6627d69f73
--- /dev/null
+++ b/git-post.sh
@@ -0,0 +1,60 @@
+#!/bin/sh
+# Copyright (c) 2017 Johannes Sixt
+
+SUBDIRECTORY_OK=Yes
+OPTIONS_SPEC="\
+git post dest-branch [source-rev]
+--
+"
+. git-sh-setup
+
+while test $# != 0
+do
+	case "$1" in
+	--)	shift; break;;
+	-*)	usage;;
+	*)	break;;
+	esac
+	shift
+done
+
+dest=$(git rev-parse --verify --symbolic-full-name "$1") || exit
+if test -z "$dest"
+then
+	die "$(gettext "Destination must be a branch tip")"
+fi
+
+shift
+case $# in
+0)	set -- HEAD;;
+1)	: good;;
+*)	usage;;
+esac
+
+# apply change to a temporary index
+tmpidx=$GIT_DIR/index-post-$$
+git read-tree --index-output="$tmpidx" "$dest" || exit
+GIT_INDEX_FILE=$tmpidx
+export GIT_INDEX_FILE
+trap 'rm -f "$tmpidx"' 0 1 2 15
+
+git diff-tree -p --binary -M -C "$1" | git apply --cached || exit
+
+newtree=$(git write-tree) &&
+newrev=$(
+	eval "$(get_author_ident_from_commit "$1")" &&
+	export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE
+	git-cat-file commit "$1" | sed -e '1,/^$/d' |
+	git commit-tree $newtree -p "$dest"
+) || exit
+
+if git check-ref-format "$dest"
+then
+	set_reflog_action post
+	subject=$(git log --no-walk --pretty=%s "$newrev") &&
+	git update-ref -m "$GIT_REFLOG_ACTION: $subject" "$dest" "$newrev" || exit
+fi
+if test -z "$GIT_QUIET"
+then
+	git rev-list -1 --oneline "$newrev"
+fi
diff --git a/t/t3514-post.sh b/t/t3514-post.sh
new file mode 100755
index 0000000000..4d31515c52
--- /dev/null
+++ b/t/t3514-post.sh
@@ -0,0 +1,77 @@
+#!/bin/sh
+
+test_description='test git post
+
+We build this history:
+
+   A--B--C  <-- master, HEAD
+  /
+ O          <-- side-base, side
+
+Then we post B and C on top of branch "side":
+
+   A--B--C  <-- master, HEAD
+  /
+ O          <-- side-base
+  \
+   B*--C*   <-- side
+
+B has a different author, which must be copied to B*.
+'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+
+	printf "a%s\n" 1 2 3 4 >file-a &&
+	printf "b%s\n" 5 6 7 8 >file-b &&
+
+	test_tick &&
+	git add file-a file-b &&
+	git commit -m initial &&
+	git tag side-base &&
+
+	test_tick &&
+	echo "Advance master" >>file-a &&
+	git commit -a -m advance-master &&
+
+	test_tick &&
+	echo "Unrelated fix" >>file-b &&
+	GIT_AUTHOR_NAME="S O Else" git commit -a -m fix-for-b &&
+
+	test_tick &&
+	echo "Another fix" >>file-b &&
+	git commit -a -m another-fix-for-b
+'
+
+test_expect_success 'post two commits on top of side' '
+
+	git branch -f side side-base &&
+	test_tick &&
+	git post side HEAD^ &&
+	test_tick &&
+	git post side &&
+
+	git log --pretty="%at %an %ae %s" HEAD~2.. >expect &&
+	git log --pretty="%at %an %ae %s" side-base..side >actual &&
+
+	test_cmp expect actual &&
+	git cat-file blob side:file-b >actual &&
+	test_cmp file-b actual &&
+
+	git diff --exit-code side-base side -- file-a	# no change
+'
+
+test_expect_success 'post requiring merge resolution fails' '
+
+	git branch -f side side-base &&
+	test_must_fail git post side HEAD
+'
+
+test_expect_success 'cannot post onto arbitrary commit name' '
+
+	git branch -f side side-base &&
+	test_must_fail git post side^0 HEAD^
+'
+
+test_done
-- 
2.14.2.808.g3bc32f2729

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

[Stefan Beller]

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. :)

>
> 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?)

> +
> +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.

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

[Johannes Sixt]

Am 05.10.2017 um 21:33 schrieb Stefan Beller:
> On Thu, Oct 5, 2017 at 12:13 PM, Johannes Sixt <j6t@kdbg.org> 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

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

[Ævar Arnfjörð Bjarmason]

On Thu, Oct 05 2017, Johannes Sixt jotted:

> Am 05.10.2017 um 21:33 schrieb Stefan Beller:
>> On Thu, Oct 5, 2017 at 12:13 PM, Johannes Sixt <j6t@kdbg.org> wrote:
>>> +git-post(1)
>>> +===========
>>> +
>>> +NAME
>>> +----
>>> +git-post - Apply a commit on top of a branch that is not checked out

It would be great to have this somehow, whatever the UI ends up being.

>> 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.

It occurs to me that a better long-term UI design might be to make
git-{cherry-pick,pick) some sort of submodes for git-commit.

Right now git-commit picks the current index for committing, but "use a
patch as the source instead" could be a submode.

Right now it commits that change on top of your checked out commit, but
"other non-checked-out target commit" could be a mode instead,
i.e. exposing more of the power of the underlying git-commit-tree.

Just food for thought.

>> * 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"?

[Not entirely serious]. Well if cherry-picking is taking a thing and
eating it here, maybe git-cherry-puke takes an already digested thing
and "throws" it elsewhere ?:)

It's a silly name but it's somewhat symmetric :)

>> * 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

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

[Johannes Sixt]

Am 13.10.2017 um 12:51 schrieb Ævar Arnfjörð Bjarmason:
> On Thu, Oct 05 2017, Johannes Sixt jotted:
>> Am 05.10.2017 um 21:33 schrieb Stefan Beller:
>>> * 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.
> 
> It occurs to me that a better long-term UI design might be to make
> git-{cherry-pick,pick) some sort of submodes for git-commit.

I don't quite agree. To commit an index state that is derived from a 
worktree state is such a common and important operation that it deserves 
to be its own command. Adding different modi operandi would make it 
confusing.

> Right now git-commit picks the current index for committing, but "use a
> patch as the source instead" could be a submode.
> 
> Right now it commits that change on top of your checked out commit, but
> "other non-checked-out target commit" could be a mode instead,
> i.e. exposing more of the power of the underlying git-commit-tree.

This is worth discussing, though not my preference. The picture to "pick 
cherries" has become quite common, and now that we use it for the name 
of the command, "cherry-pick", the direction of flow is quite obvious 
and strongly implied: from somewhere else to me (and not to somebody else).

> [Not entirely serious]. Well if cherry-picking is taking a thing and
> eating it here, maybe git-cherry-puke takes an already digested thing
> and "throws" it elsewhere ?:)
> 
> It's a silly name but it's somewhat symmetric :)

One of the decisions to be made is whether to begin the new command with 
"git-cherry-" or not, because it introduces a new abiguity for command 
line completion.

-- Hannes

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

[Rafael Ascensao]

> This is worth discussing, though not my preference. The picture to "pick
> cherries" has become quite common, and now that we use it for the name of
> the command, "cherry-pick", the direction of flow is quite obvious and
> strongly implied: from somewhere else to me (and not to somebody else).

What if we borrow '--onto' from rebase and make it cherry-pick --onto
<destination>?

This would keep the "pick cherries" analogy, but add the "they're not
for me" intention.
It also carries a bit of the "transplant" meaning of rebase.

-Rafael Ascensão

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

[Johannes Sixt]

Am 17.10.2017 um 01:01 schrieb Rafael Ascensao:
>> This is worth discussing, though not my preference. The picture to "pick
>> cherries" has become quite common, and now that we use it for the name of
>> the command, "cherry-pick", the direction of flow is quite obvious and
>> strongly implied: from somewhere else to me (and not to somebody else).
> 
> What if we borrow '--onto' from rebase and make it cherry-pick --onto
> <destination>?

I actually like this. Although I would miss the convenience that the 
source defaults to HEAD. Unless we make a special case for --onto, that 
is, of course.

-- Hannes

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

[Igor Djordjevic]

On 17/10/2017 19:30, Johannes Sixt wrote:
> Am 17.10.2017 um 01:01 schrieb Rafael Ascensao:
>>> This is worth discussing, though not my preference. The picture to "pick
>>> cherries" has become quite common, and now that we use it for the name of
>>> the command, "cherry-pick", the direction of flow is quite obvious and
>>> strongly implied: from somewhere else to me (and not to somebody else).
>>
>> What if we borrow '--onto' from rebase and make it cherry-pick --onto
>> <destination>?
> 
> I actually like this. Although I would miss the convenience that the 
> source defaults to HEAD. Unless we make a special case for --onto, 
> that is, of course.

I second this.

From my point of view, I would say that "cherry-pick" in general 
seems to just imply "taking" commits (picking "cherries"), where 
direction flow is irrelevant, or at least not strongly implied. For 
me, it`s more "from somewhere else to somebody else", indeed.

The fact that it currently "posts" its picks "to me" (on top of 
current HEAD) could very well be justified/explained as the most 
obvious case (at time of implementation, at least), where usually one 
does work "here" (HEAD), thus cares to have commits picked over 
"here" as well - but it doesn`t have to be a restriction, where other 
destination besides HEAD could/should be allowed.

Anyway, I`d say current behaviour without "--onto" should stay, 
indeed, where HEAD destination is implied if not otherwise specified 
(and that seems to align well with some other Git commands, too). 
Also, in case "--onto" _is_ provided, maybe commit to be picked could 
be allowed to be omitted, defaulting to HEAD again, but as source 
this time.

That said, might be 'git commit' looks like a nice candidate for 
being taught this new trick as well (optionally commit to a revision 
other than HEAD, what Ævar already mentioned), following the same 
logic... ;) It would even be a better (more straightforward) fit for 
one of your previous examples:

> 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.

p.s. I`m very interested in this functionality, and more - I have a 
beginner`s attempt in addressing a similar use-case this topic is 
concerned with (symptomatically using a variation of "--onto" as well 
:P), hopefully I`ll sent out something soon, for the sake of 
discussion/opinion, at least :(

Regards,
Buga