Junio C Hamano [off-list ref] writes:
So I think it is just the matter of coming up with a clever syntax that
works on reflogs to name the nth last branch we were on and teach that
syntax to both get_sha1() and resolve_ref().
With the attached illustration patch,
$ git checkout junk
$ git chekcout master
$ git checkout @{-1}
will take you back to junk branch. It probably would serve as a starting
point, if anybody is interested.
NOTE!
...
* interpret_nth_last_branch() is not hooked to get_sha1() codepath in
this patch, so this is still only applicable to "git checkout". But it
should be trivial to do so.
...
+/*
+ * This reads "@{-N}" syntax, finds the name of the Nth previous
+ * branch we were on, and places the name of the branch in the given
+ * buf and returns 0 if successful.
+ *
+ * If the input is not of the accepted format, it returns a negative
+ * number to signal an error.
+ */
+int interpret_nth_last_branch(const char *name, struct strbuf *buf)
A few more things to note.
* interpret_nth_last_branch() probably should return how many bytes it
consumed, instead of returning 0 in the successful case. This is to
allow things like "git merge @{-1}~2" to be easily parsed, either by
"git merge" itself into "git merge junk~2", which would result in
"Merge branch junk (early part)", or by get_sha1() which would result
in "Merge commit deadbeefacebeads".
* I mentioned resolve_ref() may need to be told about this syntax but I
do not think it is necessary. If a command that can take an arbitrary
refname or committish in the most general case does something special
when the end user input is a branch name ("git checkout" is a prime
example for this, but "git merge" also has this property, illustrated
by the previous "Merge branch junk" example), these commands has to do
their own special case logic before the user input hits get_sha1() or
resolve_ref() anyway (setup_branch_path() in builtin-checkout.c is a
good example of this), and such special case logic can and probably
should use interpret_nth_last_branch() directly.