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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to