Re: rebuild repo from data, packfiles?

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Nov 21, 2010, 04:19 UTC
Message-ID: <20101121041915.GA11884@burratino>
In-Reply-To: <auto-000024045181@sci.utah.edu>

Hi again,

Just a few more quick hints.

tom fogal wrote:

Show 7 quoted lines

> I can't run it on the repository as-is.  After adding some metadata in
> .git (i.e. refs, config, HEAD), I get a lot of:
> 
>   broken link from    tree a22ef5ea2d15b29ccff0bd64aa2fa2c3259ea201
>                 to    blob 23ffd9cc867a2db93d0eb991383e29243dc4db51
> 
> and then many "dangling commit"s + "missing blob"s.

Nice. If you're only missing blobs, that's much better than missing trees or commits. You might be able to use

 git rev-list --objects --all

to get some sense of paths for the blobs (and trees, if any) that are missing.

> Sorry, yes, this is what I meant.  I'm hoping I can introduce a couple
> "oops, mucked up the history" gigantic commits into the middle of the
> history, created by saying "i know that I'm missing commits between
> these two; give me the tree diff here"

Thanks, I missed that before.

(In such a case I would use "git archive" to pull out the trees since the result is closer to the actual data that is available, but your approach is equally sane.)

> It probably helps that the server is svn; my history is completely
> linear (OTOH, if we were using git, I'm sure I would have cloned this
> at home instead of ssh'ing to work on it at various points...).

Ah! You can also try using "git svn clone" to re-fetch the remote repo and then include those objects in the .git/objects directory. If you're lucky, some of the missing blobs (or even trees or commits) will be there. :)

> Don't I wish... this was just my workstation's copy.  There is of
> course the subversion repo && other clones of those revisions.

(or grab the pack and .idx from another clone)

> I had simply waited too long to push, and now I'm paying the price...

Yes, I made the same kind of mistake yesterday (wiped out the .git dir completely) and ended up re-creating patches from the worktree.

> ./logs:
> total 96
> -rw-r--r-- 1 tf tf 95572 2010-11-04 16:01 HEAD
> drwxr-xr-x 4 tf tf    44 2010-10-26 17:13 refs

[etc]

These can be used to recover the refs in .git/refs, if any of the branches is particularly important. Once you've found the right log entry,

	git update-ref <full ref name> <commit id> ""

will do it. For example, something like this would print commands to revive all branches:

	find .git/logs -type f -exec sh -c '
		refname=${1#.git/logs/} &&
		if test "$refname" = HEAD
		then
			exit 0
		fi &&
		printf "$refname " &&
		head -1 "$1"
	' - {} ';' |
	cut -d' ' -f1,3 |
	while read refname value
	do
		echo git update-ref "$refname" "$value" \"\"
	done