On 12/15/2011 09:40 PM, Neal Kreitzinger wrote: > On 12/14/2011 4:17 AM, Leonardo Kim wrote: >> 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@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html