Re: GIT vs Other: Need argument

Carl Worth <cworth@cworth.org> writes:

For some time when people compared hg and git they said git supports multiple branches in repository more naturally. And using more than one branch in a single repository, especially in one with a working tree, is more convenient for certain things, such as comparing the branches (both "diff A B" and "log A..B").

But that does not necessarily mean we are forced to use as small number of repositories as possible and use branches to represent related work.

If for example all the kernel related repositories in kernel.org were actually represented as a single repository with hundreds of branches, with default set to Linus's 'master', people who would want to track subsystem maintainers' trees would feel less convenient as they always have to first clone (perhaps with -n because they are not interested in a checkout of Linus's tree) and then 'checkout -b' for the subsystem branch of their choice.

But that is not how the kernel group organize the repositories for their project. Each subsystem maintainer have his own tree or trees, and a repository can be about a topic or various degree of doneness. So at that level, all repositories are equal and it is just a matter of picking the right URL to clone from.

Instead of trying to make each branch the target of 'clone' intended for one class of audience as your message implies, you could publish one repository (you might arrange them to share the objects via alternates to reduce storage requirements, but that is an implementation detail and invisible to your users) per an intended class of your audience. Your work, inside one repository done on multiple branches, could be pushed into more than one repositories, each of which has "the default" (and possibly "only") branch set to point at the theme of your branch in your local repository.

I think something like this might even work out of the box. On the public box you publish your branch A and B on, have three repositories (i.e. number of branches plus one) like this:

	cw-master.git/
        cw-A.git/
        cw-B.git/

Everything under cw-$X.git (for X in A B) are symlinks to the corresponding place in cw-master.git/, except HEAD. Make cw-A.git/HEAD points at refs/heads/A while cw-B.git/HEAD points at refs/heads/B.

And the maintainer (you) would push into cw-master.git/ and tell people about cw-$X.git repositories but not necessarily about cw-master.git/ repository.

Do not complain that the above is cumbersome to set up, not just yet. That is not my point. The point is that you are trying to solve this from the consumer side, but I am wondering if this is actually a problem on the publisher side. And _if_ the problem is on the publishing side, git-clone on the client side to track different branch is not the way to solve that problem. Rather, git-clone (or maybe a new program git-publish-repository) to make it easier to set up the publishing side might be what we need.