Re: GIT vs Other: Need argument

[Junio C Hamano <junkio@cox.net>]

Carl Worth <cworth@cworth.org> writes:

> So, currently, all non-default branches have a sort of second-class
> status from the point of view of users that just want to track
> them.

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.