Thank you for the feedback!
> Imagine the case where there are more than one branches
> whose tip points at the commit you came from.
> name-rev will not be able to pick correctly which one to report.
I see. Yes, you're exactly right; the following demonstrates
the problem:
$ git checkout -b xylophone master
$ git checkout -b aardvark master
$ git name-rev --name-only @{-1} # I'd want "xylophone", but this
outputs "aardvark"
So it appears name-rev is not up to the task here.
> I think you would want to use something like:
>
> upstream_name=$(git rev-parse --symbolic-full-name @{-1})
> if test -n "$upstream"
> then
> upstream_name=${upstream_name#refs/heads/}
> else
> upstream_name="@{-1}"
> fi
>
> if the change is to be made at that point in the code.
I agree, I will re-roll the patch to use this approach.
> I also wonder if "git rebase @{-1}" deserve a similar translation
> like you are giving "git rebase -".
Personally, I've been using the "-" shorthand with "git checkout"
for a year or so, but only learned about "@{-1}" a few months ago.
I think those who use "@{-1}" are familiar enough with the concept
that they don't need to have the reference translated to a symbolic
full name. Users familiar with "-" might not be aware of "@{-1}",
however, so I'd prefer not to output it as we are currently.
Furthermore, were we to translate "@{-1}", does that mean we
should also translate "@{-2}" or prior? I don't think that's the case,
but then only translating "@{-1}" would seem inconsistent.
>From that point of view I'd prefer to simply translate "-",
not "@{-1}".
- Brian Gesiak
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html