On Mon, May 12, 2008 at 2:36 PM, Nicolas Pitre <nico@xxxxxxx> wrote: > On Mon, 12 May 2008, Teemu Likonen wrote: > > > Nicolas Pitre wrote (2008-05-12 14:56 -0400): > > > > > On Mon, 12 May 2008, Teemu Likonen wrote: > > > > > > > Well, I don't really have any problems with the current behaviour; > > > > it just feels a bit strange that, for example, Linus's kernel > > > > repository grew about 90MB after just one update pull and gc. > > > > > > That looks really odd. Sure the repo might grow a bit, but 90MB seems > > > really excessive. How many time did pass between the initial clone > > > and that subsequent pull? > > > > As I used the kernel repo just for testing this behaviour in question > > I did both things today. Timestamps tell that there were six hours > > between the initial .keep pack and the new pack created by manual "git > > gc". > > This is way too big a difference. Something is going on. > > What git version is this? And can you send me the content of your > .git/logs directory? > > > > > > Also, dangling objects are kept forever in .keep packs (which are > > > > created with "git clone", for example). > > > > > > A pack obtained via 'git clone' will never contain any dangling > > > objects. > > > > I think it can contain at some later point. For example, if a user first > > fetches all the branches but later decides to track only one branch. > > After deleting unneeded tracking branches and expiring the reflog > > there'll be dangling objects in the original .keep pack created with > > "git clone". > > Sure. But to decide to track only one branch and exclude the others > require some higher level of git knowledge already. At that point if > you really care about top packing performances you certainly can deal > with the .keep file as well. > > I have had some similar problems with .keep files. I cloned a repo I created that had a branch that I wasn't interested in. I deleted the branch and then I could never get rid of the (large) number of objects in that pack until I deleted the .keep and repacked. I think there should be some way of forcing git to fix this sort of thing. It gets even worse, I had pushed up the branch I wanted to get rid of to my hosted server and there was no way to get git to release that disk space. I had to have the hosting admin send me a tarball of the repo, extract it, delete the .keep file and repack it then send it back to him. I was fortunate enough to have a service that would let me do that. Thanks, Govind. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
