> I still think that it would make the most sense to do the following
> (if you insist on some sort of automated repair):
> (1) Fetch a "good" clone (or clones) into a temporary directory;
> (2) Cannibalize the objects from it (them);
> (3) Re-run git fsck and check for still-missing / unreachable items;
> (4) IF THE RESULT OF (3) IS ACCEPTABLE, run git gc to clean up the
> mess, discard / "merge" duplicate objects, and fix up the packfiles.
> It is step (4) that requires the most user interaction. I could see
> building up a shell script that does all but (4) nearly
> automatically.
> None of this requires modifying Git itself.

Well, I'd like to have some really automatic mode, which does
everything ondemand.

Once we've got this not just for repair, but also to support
quick partial clones that fetch more objects when required.

In fact, finally, I'd like to have some storage cloud where
data automatically gets replicated to nodes which need the data,
not just for VCS, but other purposes (backup, filestore, etc) too.
But before inventing someting completely new (reinventing much
of the wheel), I'd like to investigate whether git can be
extended into this direction step by step.

Mit freundlichen Grüßen / Kind regards 

Enrico Weigelt 
VNC - Virtual Network Consult GmbH 
Head Of Development 

Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59

enrico.weig...@vnc.biz; www.vnc.de 
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to