git branch command is incompatible with bash

Hello!

I hope posting this to this mailing list is okay, this is the first ever mail that I submit to a technical mailing list.

When using the git branch command, git uses a '*' to denote the current branch. Therefore, in bash this:

	$ branchName=$(git branch -q)
	$ echo $branchName

produces a directory listing, because the '*' is interpreded by the shell.

While an (unwieldly) workaround exists:

	$ branchName=$(git symbolic-ref -q HEAD)                                                                            
	$ branchName=${branch##refs/heads/}

it would still be nice, if there were a --current flag, that returned only the current branch name, omitting the star:

	$ branchName=$(git branch --current -q)
	$ echo $branchName
	master

Am 27.07.2015 um 14:12 schrieb Anatol Rudolph:

Of course. You would write the last line as

   echo "$branchName"

These are shell fundamentals.

If you want to do that in a script, this is not a work-around, but it is how you should do it. But you may want to use option --short to save the second line.

Try

   branchName=$(git rev-parse --abbrev-ref HEAD)

-- Hannes

Johannes Sixt <j6t@kdbg.org> writes:

Hmm, interesting.

    $ git checkout --orphan notyet
    $ git rev-parse --abbrev-ref HEAD
    $ git symbolic-ref --short HEAD

Am 27.07.2015 um 23:49 schrieb Junio C Hamano:

Please don't scare newcomers with these corner cases ;-)

I see this:

$ git rev-parse --abbrev-ref HEAD HEAD fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' $ git symbolic-ref --short HEAD notyet

Are you trying to say that the result of 'rev-parse --abbrev-ref HEAD' is suboptimal and that of 'symbolic-ref --short HEAD' is OK?

-- Hannes

W dniu 2015-07-28 o 09:28, Johannes Sixt pisze:

:-P

Yet another corner case:

   $ git checkout origin/master # or v1.0.0
   $ git rev-parse --abbrev-ref HEAD
   $ git symbolic-ref --short HEAD

Errr... this error message is errorneous (well, at least somewhat misleading). Git should know that HEAD is not a path, and that --abbrev-ref doe not need no revision.

Johannes Sixt <j6t@kdbg.org> writes:

My "Interesting" was primarily about that I wasn't aware of the "--abbrev-ref" option.

Yes, I am sure some time ago I accepted a patch to add it, but I simply do not see the point, especially because the "--short" option to symbolic-ref feels much more superiour. "What branch am I on?" is about symbolic refs, rev-parse is about revisions.

I can see that "symbolic-ref --short" is much newer than the other one, so addition of "--abbrev-ref" to "rev-parse" may have been a mistake made while being desperate (i.e. not having a way to do so with plumbing, we wanted "some" way to do so and chose poorly).

On Tue, Jul 28, 2015 at 08:23:40AM -0700, Junio C Hamano wrote:

I think --abbrev-ref can handle much more than just shortening symrefs, though:

E.g. resolving other symbolic names:

  $ git rev-parse --abbrev-ref @{u}
  origin/master

Or resolving any arbitrary name you happen to have:

  $ git rev-parse --abbrev-ref refs/heads/master
  master

Even ones that aren't fully qualified (which would be tough to do with simple pattern substitution):

  $ git rev-parse --abbrev-ref remotes/origin/master
  origin/master

Or handling ambiguities during abbreviation:

  $ git tag master
  $ git rev-parse --abbrev-ref HEAD
  heads/master

-Peff

Am 28.07.2015 um 17:23 schrieb Junio C Hamano:

Heh. Originially, I was about to suggest

    git symbolic-ref -q --short HEAD || git rev-parse --abbrev HEAD

in order to handle the detached HEAD case by printing the abbreviated commit name, only to learn that this doesn't do what I expected. Looking at the man page of rev-parse, I discovered --abbrev-ref. And learned that I actually should have used --short instead of --abbrev in the above rev-parse command.

Confusing...

-- Hannes

On Tue, Jul 28, 2015 at 08:23:40AM -0700, Junio C Hamano wrote:

Sometimes my question is "what branch am I on?" -- in which case symbolic-ref is adequate.

Other times, my question is "where am I/what did I check out?" which is usually a branch, sometimes a tag, and sometimes a commit hash. We don't have a one-stop-shop command to answer that question in all cases, which is unfortunate.

git status answers, but that's not plumbing. git-prompt manages to do a fairly good job, but the logic is by no means straightforward.