Mark Mielke wrote:
> Alvaro Herrera wrote:
>> Mark Mielke wrote:
>>
>>> 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.
>>>
>>
>> That's not the problem. The problem is that it is kept in the same
>> directory as the checked out copy. It would be a lot more usable if it
>> was possible to store it elsewhere.
>>
>
> I'm not following. CVS and SVN both kept such directories "in the
> checked out copy." Recall the CSV/*,v files?
Umm, no. there are *no* ,v files in my working copies (I just checked,
to make sure I wasn't on crack). The repository has them, but the
working copy does not. SVN does keep the equivalent - that's how you can
work offline for doing things like 'svn diff'. But it makes the repo
quite ugly, in fact. Running recursive grep on a subversion working copy
is quite nasty.
>
> As for storing it elsewhere - if you absolute must, you can. There is
> a --git-dir=GIT_DIR and --work-tree=GIT_WORK_TREE option to all git
> commands, and GIT_DIR / GIT_WORK_TREE environment variables.
>
> 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. :-)
>
>
Well, it looks like the extra storage for my current 6 (soon to be 7)
working copies of postgres over the CVS equivalents would cost something
over 100Mb each. I know disk space is cheap but that's kinda sad. The
volume of info kept in CVS metadata files is insignificant. Saying they
are the same is just not so.
Is it possible for multiple working sets to share the same GIT_DIR?
cheers
andrew