Alex Riesen <fork0@xxxxxxxxxxx> wrote: > Junio C Hamano, Sun, Nov 12, 2006 20:41:23 +0100: > > Since this is not everyday anyway, a far easier way would be to > > clone-pack from the upstream into a new repository, take the > > pack you downloaded from that new repository and mv it into your > > corrupt repository. You can run fsck-objects to see if you got > > back everything you lost earlier. > > I get into such a situation annoyingly often, by using > "git clone -l -s from to" and doing some "cleanup" in the > origin repository. For example, it happens that I remove a tag, > or a branch, and do a repack or prune afterwards. The related > repositories, which had "accidentally" referenced the pruned > objects become "corrupt", as you put it. > > At the moment, if I run into the situation, I copy packs/objects from > all repos I have (objects/info/alternates are useful here too), run a > fsck-objects/repack and hope nothing is lost. It works, as I almost > always have "accidental" backups somewhere, but is kind of annoying to > setup. A tool to do this job more effectively will be very handy (at > least, it wont have to copy gigabytes of data over switched windows > network. Not often, I hope. Not _so_ many gigabytes, possibly). One of my coworkers recently lost a single loose tree object. We suspect his Windows virus scanner deleted the file. :-( Copying the one bad object from another repository immediately fixed the breakage caused, but it was very annoying to not be able to run a "git fetch --missing-objects" or some such. Fortunately it was just the one object and it was also still loose in another repository. scp was handy. :-) -- Shawn. - 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