Tom Lane wrote:
> 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
I am curious about why an end user would really care? CVS and SVN both
kept local workspace directories containing metadata. If anything, I
find GIT the least intrusive of these three, as the .git is only in the
top-level directory, whereas CVS and SVN like to pollute every directory.
Assuming you don't keep binaries under source control, the .git
containing all history is very often smaller than the "pristine copy"
kept by CVS or SVN in their metadata directories, so space isn't really
the issue.
Maybe think of it more like a feature. GIT keeps a local cache of the
entire repo, whereas SVN and CVS only keeps a local cache of the commit
you are based on. It's a feature that you can review history without
network connectivity.
Cheers,
mark
--
Mark Mielke <mark@mielke.cc>