Alvaro Herrera <alvherre@commandprompt.com> writes:
> Hmm, but is there a way to create those clones from a single local
> "database"?
> (I like the monotone model much better. This mixing of working copies
> and databases as if they were a single thing is silly and uncomfortable
> to use.)
I agree, .git as a subdirectory of the working directory doesn't make
much sense to me.
I wondered for a second about symlinking .git from several checkout
directories to a common master, but AFAICT .git stores both the
"repository" and status information about the current checkout, so
that's not gonna work.
In the one large project that I have a git tree for, .git seems to
eat only about as much disk space as the checkout (so apparently the
compression is pretty effective). So it wouldn't be totally impractical
to have a separate repository for each branch, but it sure seems like
an ugly and klugy way to do it. And we'd still end up with the "same"
commit on different branches appearing entirely unrelated.
At the same time, I don't really buy the theory that relating commits on
different branches via merges will work. In my experience it is very
seldom the case that a patch applies to each back branch with no manual
effort whatever, which is what I gather the merge functionality could
help with. So maybe there's not much help to be had on this ...
regards, tom lane