Hi Peter,
This didn't work. I've cloned my git repo and copied the pack into

packs/objects without the .keep file and removed objects/info/packs.

After that I ran repack -a -d -f, but nothing changed. I still can't

access the parent of e0fda6ab. What else can I do?
Bye, Jörg.

--

The social dynamics of the net are a direct consequence of the fact

that nobody has yet developed a Remote Strangulation Protocol.

            (Larry Wall)

--

Please have a look at this:
http://git.or.cz/gitwiki/GitFaq#head-ac11406480d09e2df98588e800e41b72566...
Regards,

Christian.
--

If you know the name of the objects you are missing, you can

make a temporary pack to transfer the list of objects:
	# at good repo

	#

	git pack-objects --stdout <object.list >save.pack
	# at bad repo

	#

	git index-pack --stdin <save.pack
Make object.list just one SHA-1 per line.  The resulting pack is

not likely to be highly compressed, as it will probably contain

a non-delta version of each object, but its faster to create than

calling git-cat-file for each object, and may give you a smaller

pack than just copying everything as the FAQ entry recommends.
Note that you may need to do this several times; e.g. if you are

missing a tree you won't know what blobs you are missing until

you load the tree and run fsck --full again to parse the tree and

discover the missing blobs.  This iterative copying approach is

what the FAQ avoids when it suggests you copy everything.
--

Shawn.

--

Hi,
I didn't know the list of objects I'm missing, but I used this little

script do find them:
anchor=3D7cb192eab0251911e2ca77d4ecceb621dd2d34f5

while true

do

    outp=3D$(git log --pretty=3Draw --raw $anchor 2>&1 >/dev/null)

    echo $outp

    [ $#outp -eq 0 ] && break

    cmt=3D${${outp##* \(}%\)}

    git cat-file -t $cmt >/dev/null 2>&1 && \

      cmt=3D$(git cat-file commit $cmt |grep '^tree ')

    echo ${cmt##* } | ssh server cd git\; git pack-objects --stdout | \

      git index-pack --stdin >/dev/null

done
Maybe it helps someone else. :)
But now, there's something else broken.
% git cat-file commit b63e99500137c913bd801a2f22b6cf88c63b95c5

tree 68a58fb97935f35c6fb7bcbcfed73b1697db000a

parent 3f061887c562b20d3ed3d1f764462cf986a1ad12

author Wincent Colaiuta <win@wincent.com> 1195996542 +0100

committer Junio C Hamano <gitster@pobox.com> 1196019475 -0800
Add "--patch" option to git-add--interactive
When the "--patch" option is supplied, the patch_update_cmd() function is

=E2=80=A6
% git cat-file commit 3f061887c562b20d3ed3d1f764462cf986a1ad12

tree 636a0f9c085aac7ba539ef2ace03b3081481891a

parent 324ccbd6a09816af830b22b02bbeb06349141849

author Junio C Hamano <gitster@pobox.com> 1196014210 -0800

committer Junio C Hamano <gitster@pobox.com> 1196014993 -0800
add -i: Fix running from a subdirectory
This fixes the pathspec interactive_add() passes to the underlying

=E2=80=A6
% git rev-parse b63e99500137c913bd801a2f22b6cf88c63b95c5~1

b63e99500137c913bd801a2f22b6cf88c63b95c5~1

fatal: ambiguous argument 'b63e99500137c913bd801a2f22b6cf88c63b95c5~1': unk=

nown revision or path not in the working tree.

Use '--' to separate paths from revisions
fsck --full reports only dangling objects, no breakage.
Bye, J=C3=B6rg.

--=20

Die zehn Gebote Gottes enthalten 172 W=C3=B6rter, die amerikanische

Unabh=C3=A4ngigkeitserkl=C3=A4rung 300 W=C3=B6rter, die Verordnung der euro=

p=C3=A4ischen

Gemeinschaft ...
[ message continues ]

I've had similar symptoms when I had circular references in the

repository.  They're not reported by any of the existing checks, I've

submitted a patch (resent it just now) which causes git to check for

(and report) circular references when using --topo-order on e.g.

git-rev-list.

--

Sincerely,                                                          srb@cuci.nl

           Stephen R. van den Berg.

--

Assuming that we never have SHA-1 hash collisions, the graft mechansim is

practically the only way to get yourself into the circular reference

situation.
Perhaps we should check this circularity when we install grafts instead of

special casing the topo-order codepath?  How expensive would that

alternative approach be?
--

Not practical in its current form.

Checking for circular references is O(n) in CPU and memory use relative

to the number of commits in the entire repository.
Consider:

- The proposed check in the topo-order path is very low-cost, it costs a

  single decrement/increment per commit (and will detect other circular

  references not caused by the grafts mechanism, if they ever should occur).

- If it is being done during the grafts install, then there should be a

  flag-file (at least), which indicates when the grafts file has changed

  since the last check.

- It could/should be added to git-fsck.

--

Sincerely,                                                          srb@cuci.nl

           Stephen R. van den Berg.

--