Junio C Hamano <gitster@xxxxxxxxx> writes: >> It might be nice to have a mechanism where new objects would update >> the _alternate_ rather than the object-store in the tree where the >> command was run. > > With the alternate mechanism, your borrowing is read-only and that is > exactly why you can borrow from other peoples' repositories to which you > have no write permission to. > > What you are suggesting is fundamentally different from the alternates > mechanism. I am not saying it is better or worse, though. Not yet at this > point in this message. Sure, and I don't even claim it's a viable idea, just something that "seems useful." >> .. then you could easily have a bunch of trees using a central >> object store without needing to update the central store >> occasionally by hand (and do gc in its "clients")... > > If you write objects to the central store, "gc" in the "clients" > will be a no-op because they do not have their own objects. But > instead, crufts your "clients" accumulate will be in the central > store. There is still need for "gc" at the central store to remove > things that are no longer used by any client, isn't it? Unless you > declare that you do not care because perhaps the central store is > large enough, that is. Sure, if git had this mode of operation, it would seem desirable for "git gc" to act on the central store just at the same points it acts on the "local store" today. As obviously a gc needs to know all the roots, that suggests the central store needs to have a list of clients it can scan for roots. [I suppose the other "problem" is locking; I guess that would technically be no different that multiple git commands running simulataneously in the same tree today, but maybe the presence of a central store would make such situations occur more frequently...] > At least with the alternates, running "gc" in the "clients" is a > safe operation and the only change necessary is to make fsck/repack > aware of the repositories that borrow from the repository these > commands are run, and the logic to do so is exactly the same as the > case to run "gc" in your central store, I would think. Hmmm sure. -miles -- ===== (^o^; (())) *This is the cute octopus virus, please copy it into your sig so it can spread. -- 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