Hi,

I am very new to git but I have thought about this a bit from a user's
perspective.  I have several thoughts on the matter.

First, I would like to point out that the hg folks like to compare
themselves to git a lot and they list the need for manual gc as a
reason to choose hg over git.  This may not be something that the git
community cares about but I thought I would point it out.

Second, it *is* a hassle.  When trying to figure out what I could
convince my co-workers to use, having to gc was something that I did
not think they would be conscious of or care enough about to do.  It
makes git more of a PITA than it could be.  Similarly, I have no idea
when it is a good time to do a gc.  After every commit?  Before push?
What if I never push a repo?  What if it is a remote repo only used to
sync up with my co-workers, do I have to go there and periodically gc?
 This is one reason why I really think that gc should be *plumbing*
and *not* porcelain.

The user should never have to trigger a gc, they should even be
discouraged from doing so.  That is how other gc systems are.  Can you
imagine if you had a Java app that had a button on it to do a gc?
When should I push it?  Should I wait till the system is getting slow
or just start spamming the button whenever I'm bored?  I know that
Java/c#/py GC are different than git gc, but they fulfill the same
basic purpose as git gc.  IE to clean up unused items and free up
resources.  Git additionally may do some re-optimization, but that is
not relevant to a user.

I know this goes against the general mood here (which seems to be
against auto-gc) but I thought I would give my $.02 as a user of git.

Thanks,
Govind.

On 9/5/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
quoted text
>
> So we had a git bof at linux.conf.eu yesterday, and I leart something
> new: even people who have been using git for a long time apparently don't
> necessarily realize the importance of repacking.
>
> James Bottomley (the Linux SCSI maintainer) is an old-time BK user, and
> very comfy using git. But when he was demonstrating things on his poor old
> laptop, simple things like "git branch" literally took a long time, and
> James didn't seem to realize that the fact that he had apparently never
> ever repacked his repository was a big deal.
>
> The kernel archive is a 190MB pack for me fully repacked (I just checked -
> I had actually thought that it was somewhat larger than that), but because
> James hadn't repacked, his .git directory was over a gigabyte in size, and
> his laptop wasn't able to cache anything at all effectively as a result.
>
> Repacking it took over an hour, simply because everything was *so*
> unpacked, and James' kernel repository had something like 92 thousand
> loose objects, and several hundred packfiles. Simple operations that
> really take much less than a second for me ("git branch" takes 0.022s on
> my laptop, which has the same 512M that James had on his) took many many
> seconds as a result, and James seemed to think that this was all normal.
>
> And James didn't even want to repack, because it was so expensive (which
> he knew - he claims to have never ever repacked at all, but maybe he had
> started it and just control-C'd it when it was really slow at some point).
>
> Now, it may be that James didn't realize how important the occasional
> garbage collect is exactly *because* he is an old-timer and used BK long
> before he used git, and just continued using git simply as a BK
> replacement, but it did make me wonder whether maybe this lack of
> repacking awareness is fairly common.
>
> I've been against automatic repacking, but that was really based on what
> appears to be potentially a very wrong assumption, namely that people
> would do the manual repack on their own. If it turns out that people don't
> do it, maybe the right thing for git to do really is to at least notify
> people when they have way too many pack-files and/or loose objects.
>
> I personally repack everything way more often than is necessary, and I had
> kind of assumed that people did it that way, but I was apparently wrong.
> Comments?
>
>                 Linus
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html