git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Enrico Weigelt <enrico.weigelt@vnc.biz>
To: Drew Northup <n1xim.email@gmail.com>
Cc: Jeff King <peff@peff.net>, git <git@vger.kernel.org>
Subject: Re: Auto-repo-repair
Date: Fri, 23 Nov 2012 00:16:34 +0100 (CET)	[thread overview]
Message-ID: <cd8ee2cf-2d4a-4d0c-931f-61de4c7f6348@zcs> (raw)
In-Reply-To: <CAM9Z-n=tAcpQHTU7WHhzZkoVL_ar9vcH8G1tKd-026+djAiJ4A@mail.gmail.com>

Hi,

> 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.


cu
-- 
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.weigelt@vnc.biz; www.vnc.de 

      reply	other threads:[~2012-11-22 23:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <0c0e34a4-16ab-40a0-9293-af94e34e4290@zcs>
2012-11-16 17:51 ` Auto-repo-repair Enrico Weigelt
2012-11-16 19:00   ` Auto-repo-repair Jeff King
2012-11-17  9:21     ` Auto-repo-repair Enrico Weigelt
2012-11-18 16:37       ` Auto-repo-repair Drew Northup
2012-11-18 16:55         ` Auto-repo-repair Enrico Weigelt
2012-11-19  3:30           ` Auto-repo-repair Drew Northup
2012-11-19 22:35             ` Auto-repo-repair Enrico Weigelt
2012-11-20 11:56               ` Auto-repo-repair Drew Northup
2012-11-22 23:16                 ` Enrico Weigelt [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cd8ee2cf-2d4a-4d0c-931f-61de4c7f6348@zcs \
    --to=enrico.weigelt@vnc.biz \
    --cc=git@vger.kernel.org \
    --cc=n1xim.email@gmail.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).