Re: Branch names with slashes

On 12/15/2011 09:40 PM, Neal Kreitzinger wrote:

On 12/14/2011 4:17 AM, Leonardo Kim wrote:

quoted

Branch names can contain slashes, so we can use 'development/foo' as
a branch name. If I choose 'development' as a branch name, it doesn't
work. There is a directory named development at '.git/refs/heads'
directory. So we cannot create a file named development for
'refs/heads/development'.

An error message may occurs like below. Unfortunately, It is not of
help to me. 'error: 'refs/heads/development/foo' exists; cannot
create 'refs/heads/development'.

I think that dealing with a file system and an error message above is
not sufficient for a novice like me. I hope that it should be
improved.

FYI, We also use slashes in our branchnames to leverage some of the
benefits of a path-like namespace like pattern matching and the logical
expression of hierarchies using descriptive compound names. (We use git
1.7.1 on linux.) Here's something to keep in mind: You have to plan
(think ahead) for your naming conventions so that the namespaces will
maintain uniqueness at a peer level over time that cannot be confused as
subdirs under .git/refs/heads. For example:

branchnames:
/mysystem/generic
/mysystem/generic/project1

will not work because /mysystem/generic appears to be a parent dir to
/mysystem/generic/project1 under .git/refs/heads.  The solution is:

/mysystem/generic/base
/mysystem/generic/project1

these branches can coexist because they are unique without one appearing
to be a parent dir of the other.  IOW, their namespaces are peers in
their entirety. To carry the example a little further,

/mysystem/generic/project1/part2
will not work because once again it appears to be a subdir of an
existing branchname (ref).  However,
/mysystem/generic/project1-part2
will work.

I think the reason for this is that if you look at .git/refs/heads you
will see that these slash delimited branch names are actually stored as
subdirs in the filesystem sense.  Therefore, git will get confused and
error out as it tries to find branchnames that are not entirely unique
by their full path namespace under .git/refs/heads because a branch
namespace that is a prefix (in the filesystem sense) of another branch
name would occupy the same path under .git/refs/heads without being
distinguishable as unique, and vice versa.

Everything that you say is correct.  And it is known, at least to a few
git implementers (i.e., not a bug but a conscious design decision).  For
example, the function is_refname_available() is used explicitly to
prevent refnames that conflict in the way that you describe *even if*
the refnames in question are packed and therefore not 1:1 with
filesystem paths.  This is all a limitation of the fact that references
*can* be represented by files and therefore they inherit the filesystem
constraint that a file and subdirectory within a single parent directory
cannot have the same name.

I don't believe that it would be possible to relax this limitations
without at least a little breakage of backwards compatibility.

What is the bottom line?  Feel free to submit patches to improve the
documentation or error reporting.  But I doubt that the underlying
limitation will be removed.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/