Re: [PATCH] Do not ignore hidden refs

[Shawn Pearce <spearce@spearce.org>]

Junio C Hamano <junkio@cox.net> wrote:
> 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.

--