On Thursday 15 October 2009, Austin, Alex wrote: > I just did a clone of the git repository and noticed how long it took > to clone one of the many objects. After a little sleuthing, I've determined > that: > 2869bc4... Adds a few small files > 2f37d16... Adds several large files. > af3b53a... Adds more large files. It immediately succeeds the previous > 1ef7ccc... Removes all files added by previous three commits and nothing else
And "git whatchanged -- zy1000" is the quick way to show them. Briefly: just over a year ago a bunch of binary snapshots got checked into the trunk rather than into the zy1000 branch, then promptly removed. And thus rather a lot of undesirable stuff is getting pulled in. I thought all those snapshots were just in that branch, but that seems not to be the story. > Removing those four commits brings the repo from 99MB to 5MB. In my experiments, it seemed to save about 100 MBytes. I'm not sure how oure experiments differed. > While doing > so would destroy history that others' use, it would be a great boon to > those who are cloning it for the first time, and would not be difficult > for the rest of us to synchronize with. > > Any takers? Looks like a .git/info/grafts file on the server might help, near term. But longer term I think it might be best to rebase to have a tree without those commits. Now, rebasing like that is something to avoid against public trees. It causes trouble in anyone actively developing against private branches against that tree. Basically, a year's worth of patches will all git new hashes; so any work using the previous hashes gets disrupted. Simplest approach is for everyone to pull new trees. But without it, we'll carry that stuff around forver ... and this tree is already slightly diverged from SVN (having dropped the various branches). So I'd kind of lean towards having a "rebase" flag day, sooner rather than later. Comments? _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
