> As git is used more and more in corporate-type environments, at some > point it becomes convenient to have *branches* (or more accurately, > refs) that are not readable. The simplest way to do this (from git's > point of view) is to allow a "pre-upload" hook, rather like the > "pre-receive" hook or "update" hook. > What's the benefit of this over using multiple repositories? For a simple case where you have public branches and private branches, you use public.git and private.git. A post-update hook in private.git can automatically push the appropriate branches to public.git (in which case they don't worry about public.git at all) or they can do it themselves. For more complex access control, give each sub-unit that needs to share work a repository that's only readable by the members of that unit. Each developer works in his own repo. When something is ready for a wider audience, he pushes it to a team repo. When a team leader has something that's ready to move up, he pushes to a group repo, etc. -- Adam -- 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