git failing to create new branches, depending on the name

One of my build scripts, which takes a 'work' git tree, clones it to make a build tree, then creates an unique branch there and goes on to do the rest of the work, started mysteriously failing recently .
Turns out git doesn't like the branch names that my script is choosing and git-checkout fails with a misleading fatal error. I don't remember changing the script recently and it used to work for months, something must have changed.

This is what i did while trying to find why the checkout is failing:

+ git --version
git version 1.6.4
+ rm -rf /tmp/build-tree
+ git clone -l -s -n -o askern --reference /tmp/work-tree /tmp/work-tree /tmp/build-tree Initialized empty Git repository in /tmp/build-tree/.git/
+ cd /tmp/build-tree
+ git branch -a | grep g90bc1a6
+ git checkout -f -b branch-g90bc1a6 askern/release
fatal: git checkout: branch branch-g90bc1a6 already exists
# WTF?
+ (
+ cd /tmp/work-tree
+ git branch -a | grep g90bc1a6
+ )

# nothing in parent repo either.
+ git checkout -f branch-g90bc1a6 
Checking out files: 100% (29109/29109), done.
Note: moving to 'branch-g90bc1a6' which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
  git checkout -b <new_branch_name>
HEAD is now at 90bc1a6... Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus
# so where is coming from?
+ git branch -a | grep g90bc1a6
+ git status
# Not currently on any branch.
nothing to commit (working directory clean)
+  git show --pretty=short 90bc1a6 | cat
commit 90bc1a658a53f8832ee799685703977a450e5af9
Merge: 6ce90c4 54822de
Author: Linus Torvalds <[email protected]>

Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus
# Aha

So what appears to be happening is that the script picks up the 90bc1a6 suffix (it gets it from git-describe), uses it as part of the branch name and then git misinterprets it. (the actual names used by the script are much longer, i used "branch-g90bc1a6" only to figure what was going on)

artur

This bisects to

commit 352eadc40024b141e1295693654ec20cc123844f

Author: Daniel Barkalow <[email protected]>
Date:   Sun Sep 21 14:36:06 2008 -0400

Check early that a new branch is new and valid

If you fail to update refs to change branches in checkout, your index and working tree are left already updated. We don't have an easy way to undo this, but at least we can check things that would make the creation of a new branch fail. These checks were in the shell version, and were lost in the C conversion.

The messages are from the shell version, and should probably be made nicer.

[jc: added test to t7201]

Not sure this is a bug though. If we allow branch names that are ambiguous to rev-parse, what do they resolve to? E.g., in the presence of only 'master', 'master-g01234567' is defined to be the same as 01234567. What is it if you also have a *branch* called 'master-g01234567'?

Thomas Rast
trast@{inf,student}.ethz.ch

well, it didn't say it didn't like the name, and sent me looking for bugs in my scripts for quite a while, until i realized what's going on...

I'd expect the branch namespace to take precedence, unless branches ending in -g01234567 are illegal, but that seems like an odd limitation.

Note that currently this works:

+ ( cd /tmp/build-tree/ && git checkout -f whatever/random-name-g90bc1a6 )
HEAD is now at 90bc1a6... Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus

which doesn't seem right either.

artur

Perhaps it shouldn't say "branch branch-g90bc1a6", but...

"branch-g90bc1a6" does already exist, in the sense that you can already check it out. It's probably a bad idea, from the point of view of having your repository make sense, to have a branch whose name is a valid name for a different commit (or, in any case, a commit not specified by the current value of the branch).

The check was added (restored, actually; it had been lost in the conversion to C) in order to prevent people from accidentally making local branches named things like "origin/master" when there's a remote branch named that.

The official documentaion on specifying revisions is in the man page for git-rev-parse (it's referenced for a bunch of places, although this is obviously not the first place you'd think to look).

The error message should probably be improved to not imply that what's already using that name is a branch.

-Daniel
*This .sig left intentionally blank*