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 <m...@mielke.cc>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
