Re: Managing multiple branches in git

Alvaro Herrera wrote:
> Mark Mielke wrote:
>
>> I just don't understand why you care. If the CVS directories didn't bug
>> you before, why does the single .git directory bug you now? I'm
>> genuinely interested as I don't get it. :-)
>>
>
> It doesn't. What bugs me is that the database (the "pulled" tree if you
> will) is stored in it. It has already been pointed out how to put it
> elsewhere, so no need to explain that.
>
> What *really* bugs me is that it's so difficult to have one "pulled"
> tree and create a bunch of checked out copies from that.
>
> (In the CVS world, I kept a single rsync'ed copy of the anoncvs
> repository, and I could do multiple "cvs checkout" copies from there
> using different branches.)
>

You say "database", but unless you assume you know what is in it, .git
isn't really different from CVS/ or .svn. It's workspace metadata. Size
might concern you, except that it's generally smaller than CVS/ or .svn.
Content might concern you, until you realize that being able to look
through history without accessing the network is a feature, not a
problem. Time to prepare the workspace might concern you, but I haven't
seen people time the difference between building a cvs checkout vs a git
clone.

You talk about avoiding downloads by rsync'ing the CVS repository. You
can do nearly the exact same thing in GIT:

1) Create a 'git clone --bare' that is kept up-to-date with 'git fetch'.
This is your equivalent to an rsync'ed copy of the anoncvs repository.
2) Use 'git clone' from your local bare repo, or from the remote using
the local bare repo as a reference. Either hard links, or as a reference
no links at all will keep your clone smaller than either a CVS or an SVN
checkout.

Mainly, I want to point out that the existence of ".git" is not a real
problem - it's certainly no worse than before.

Cheers,
mark

--
Mark Mielke <mark(at)mielke(dot)cc>