Re: [PATCH] Do not ignore hidden refs

From: Shawn Pearce <spearce@spearce.org>
Date: Nov 18, 2006, 07:41 UTC
Message-ID: <20061118074119.GA2338@spearce.org>
In-Reply-To: <7vzmapdxki.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> wrote:

Show 9 quoted lines

> Personally I established a convention to treat heads/??/* as
> "private namespace" while using heads/* as public refs for my
> own work (I do that for git.git as people know, and I do that
> for my day job project as well).  I do not think it is a great
> enough convention to be promoted as the official BCP, but it has
> been good enough for me, especially commands like "show-branch"
> and "tag -l" understands the shell-style filegrobs (e.g
> "show-branch master heads/??/*" would show what's yet to be
> polished and merged).

We use refs/heads/??/* as "developer specific" namespaces.

That is we use an update hook in our central repository to control who can push into refs/heads/??/*. If ?? matches the unix account holder's initials then they can push into that name, otherwise they can't. This prevents any sort of naming collisions between developers.

To make things slightly easier I've also suggested that people name their local branches with the same ??/ prefix as they need to use on the central repository, thereby making the branch name the same everywhere. This is actually one reason why git-completion.bash suggests "??/foo:??/foo" when completing a branch name to git-push. :)

So I don't think its a great idea to assume by default that refs/heads/??/* is private to this repository.

Though on second thought maybe we should be using developer private repositories with object alternates pointing at a central repository. But that means users have to manipulate URLs to fetch another developer's branch vs. just using an existing remote.<nick>.url, which is the main reason we put everything into one repository.