Re: should git download missing objects?

fork0@t-online.de (Alex Riesen) writes:

Junio C Hamano, Sun, Nov 12, 2006 20:41:23 +0100:

quoted

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

I suspect it is a different issue.  Maybe you would need reverse
links from the origin directory to .git/refs/ directroy of
repositories that borrow from it to prevent pruning.  No amount
of butchering fetch-pack to look behind incomplete refs that lie
and claim they are complete would solve your problem if you do
not have any "accidental backups".

In general, 'git clone -l -s' origin directories may not be
writable by the person who is making the clone, so we should not
do this inside 'git clone'.  Also you could add alternates after
you set up your repository, so maybe something like this would
help?

	#!/bin/sh
	#
	# Usage: git-add-alternates other_repo
        #
        : ${GIT_DIR=.git}
	my_refs=`cd $GIT_DIR/refs && pwd`
	other=$1
        test -d "$other/.git" && test -d "$other/objects" || {
        	echo >&2 "I do not see a repository at $other"
                exit 1
	}
	mkdir -p "$other/.git/refs/borrowers" || {
        	echo >&2 "You cannot write in $other"
        	echo >&2 "Arrange with the owner of it to make"
        	echo >&2 "sure the objects you need are not pruned."
                exit 2
        }
	cnt=0
        while test -d "$other/.git/refs/borrowers/$cnt"
        do
		cnt=$(($cnt + 1))
	done
        ln -s "$my_refs" "$other/.git/refs/borrowers/$cnt"

Junio C Hamano, Mon, Nov 13, 2006 21:05:48 +0100:

quoted

Junio C Hamano, Sun, Nov 12, 2006 20:41:23 +0100:

quoted

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

I suspect it is a different issue.  Maybe you would need reverse
links from the origin directory to .git/refs/ directroy of
repositories that borrow from it to prevent pruning.  No amount
of butchering fetch-pack to look behind incomplete refs that lie
and claim they are complete would solve your problem if you do
not have any "accidental backups".

It's is not about preventing this from happening. It is about
recovering from user error (which I plainly did). The discussion about
"git fetch --recover" sound very much like what would helped in that
situation. I'll just try not doing it next time, but if I do, it'd be
nice to have a tool to help me recover from it. Not prevent, not
seeing it possible, just help.

Anyway, it's kind of too late for that repositories. And not very
convenient to work with: the branches in the slave repos come and go
often, they pull from each other and push into central (aka origin)
repo. Maintain the borrowed refs in sync would be nightmare (as is: "I
promise to forget doing it").