Re: [BUG] branch renamed to 'HEAD'

Jacob Keller <jacob.keller@gmail.com> writes:

There are two kinds of callers to i-b-n. The ones that want a local branch name because they are parsing special places on the command line that using a local branch name makes difference (as opposed to using any extended SHA-1 expression), like "git checkout master" (which means different thing from "git checkout master^0"). And the ones that can use any object name.

It depends on how your flag works, but if it means "add refs/heads/ when you got a local branch name", then that would not work well for the former callers, as end-user inputs @{-1} and refs/heads/master would become indistinguishable. The former is expanded to 'master' (if you were on that branch) and ends up being refs/heads/master. "git checkout refs/heads/master" would be (unless you have a branch with that name, i.e. refs/heads/refs/heads/master) a request to detach HEAD at the commit, but the user wanted to be on the previous branch. And the latter iclass of callers are probably already happy with or without the flag, so they won't be helped, either.

A flag to affect the behaviour (as opposed to &flag as a secondary return value, like Peff's patch does) can be made to work. Perhaps a flag that says "keep the input as is if the result is not a local branch name" would pass an input "@" intact and that may be sufficient to allow "git branch -m @" to rename the current branch to "@" (I do not think it is a sensible rename, though ;-). But probably some callers need to keep the original input and compare with the result to see if we expanded anything if we go that route. At that point, I am not sure if there are much differences in the ease of use between the two approaches.