On Wed, 11 Apr 2007, David Lang wrote:Well, just from a personal observation: - I would *personally* actually refuse to share objects with anybody else. I just find the idea too scary. Somebody doing something bad to their object store by mistake (running "git prune" without realizing that there are *my* objects there too, or just deciding that they want to play with the object directory by hand, or running a new fancy experimental importer that has a subtle bug wrt object handling or anything like that). I'll endorse use "alternates" files, but partly because I know the main project is safe (any alternates usage is in the "satellite" clones anyway, and they will never write to the alternate object directory), and partly because at least for the kernel, we don't have branches that get reset in the main project, so there's no reason to fear that a "git repack -a -d" will ever screw up any of the satellite repositories even by mistake. But for git projects, even alternates isn't safe, in case somebody bases their own work on a version of "pu" that eventually goes away (even with reflogs, pruning *eventually* takes place). So I tend to think that alternates and shared object directories are really for "temporary" stuff, or for *managed* repositories that are at git *hosting* sites (eg repo.or.cz), and where there is some other safety involved, ie users don't actually access the object directories directly in any way. So I've at least personally come to the conclusion that for a *developer* (as opposed to a hosting site!), shared object directories just never make sense. The downsides are just too big. Even alternates is something where you just need to be fairly careful! 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
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Alan Cox | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | Re: [GIT]: Networking |
| Evgeniy Polyakov | Re: [BUG] New Kernel Bugs |
