Jeff King [off-list ref] writes:
On Mon, Nov 14, 2011 at 09:48:07AM +0100, Simon Brenner wrote:
quoted
On Mon, Nov 14, 2011 at 7:06 AM, Miles Bader [off-list ref] wrote:
quoted
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... 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")...
This sounds like a nice way forward: replace/extend the current
alternates system ...
Yes, I think that is sensible. I'm not sure there is even any core git
code to be written. I think a wrapper that does the following would
probably work:
I agree with your outline, which I find is in line with what I had in mind
in the message Miles responded.
The approach is different from what Miles alluded to, which is to have
"clients" create objects in the "central" place in the first place,
though.
On Mon, Nov 14, 2011 at 12:18:25PM -0800, Junio C Hamano wrote:
quoted
Yes, I think that is sensible. I'm not sure there is even any core git
code to be written. I think a wrapper that does the following would
probably work:
I agree with your outline, which I find is in line with what I had in mind
in the message Miles responded.
The approach is different from what Miles alluded to, which is to have
"clients" create objects in the "central" place in the first place,
though.
It seems to me that is simply an optimization that can come later. An
initial, no-C-code implementation would write to individual repos as
usual, and then occasionally migrate objects to the master shared repo
(and remove duplicates from individual repos). That's an easy to
implement low-risk experiment from which we can draw conclusions about
how well such a system works in practice.
And then if it seems like a good path, an obvious optimization[1] is to
write directly into the parent object store, skipping the migration.
This might involve git-core code, or maybe it just means setting up the
repos differently (e.g., symlinking the objects directory to the master
store).
-Peff
[1] Actually, I am slightly dubious that this optimization is worth
doing. It seems like it would save you from writing the data only to
copy it later. But in practice, we write loose objects, and you are
already rewriting the data to migrate it into packfiles. So the
migration already happens, and instead we would just be migrating to
packfiles in the central repo.