i run git gc clean files , improve performance, cronjob. however, use git-new-workdir create new working directory own index.
does make sense run git gc on each of working directories? why?
no, because underlying repository shared separate working directories, , git gc operates on underlying repository.
there's additional (minor real) danger here. when run git gc, cleans , compresses repository objects, discarding unreferenced. references may, in cases, in index, or in head (in "detached head" mode). note in description of git-new-workdir, says, in part:
it sets new working directory (with own index) you.
references hidden in other index—i.e., index not 1 seen work-dir—are invisible git gc, making them eligible removal.
most of time not going problem because git gc runs git prune default expiration time (i.e., 2 weeks) unreferenced objects. index-only reference occurs when git add file don't git commit result, these apparently-stale references go away if leave git added files uncommitted @ least 2 weeks ... , can fix problem git add-ing file(s) again needed.
a more insidious version occurs use of detached head create anonymous branch. page linked not mention it, new-workdir script not (and cannot) maintain such detached heads across separate "new work dirs" (each of these new directories has own .git directory own separate head reference). 2 or more week old chain of detached commits discarded underlying repository if git gc run in other work directory.
this not problem "real" branches , tags script shares "deeper" references (including branches , tags). is, updating branch x in 1 work-dir updates branch x in other work-dirs, there's no way lose reference.
in short (too late? :-) ) you're reasonably safe if don't keep detached heads out more week.
