Re: unable to get type of object

[Jeff King <peff@peff.net>]

On Wed, Jun 01, 2011 at 09:11:07AM +0200, Robert Garrigos wrote:

> ************
> predircam@eduab:~/public_html/idosing> git pull
> Generating pack...
> Done counting 117 objects.
> error: unable to find c3117d23df0c01ba8558bad81ad3488f0e8d430a
> fatal: unable to get type of object c3117d23df0c01ba8558bad81ad3488f0e8d430a
> fatal: early EOF
> fatal: git-unpack-objects died with error code 128
> Fetch failure: /home/predircam/gitrepos/idosing.git
> ***************
> 
> google suggests me to run git fsck to get a list of corrupted files.
> Besides that I'm running git 1.2.4 and that the git command for that
> version is fsck-objects, I'm not having any result at all.

Wow, that's pretty ancient by git standards.

> Could this be a compatibility problem? As I said, I run git 1.2.4 on
> the repo server and git 1.7.0.2 on my development server. BTW, on my
> devel server running the git command fsck gives no result either.

It could be. In the 1.6.x series we started using some newer encodings
for packfiles and their associated indexes. From the 1.6.0 release
notes:

  By default, packfiles created with this version uses delta-base-offset
  encoding introduced in v1.4.4.  Pack idx files are using version 2
  that allows larger packs and added robustness thanks to its CRC
  checking, introduced in v1.5.2 and v1.4.4.5.  If you want to keep your
  repositories backwards compatible past these versions, set
  repack.useDeltaBaseOffset to false or pack.indexVersion to 1,
  respectively.

However, note that this is for the _local_ pack storage. When two git
versions are talking to each other on the network, they will negotiate
the use of delta-base-offsets (and the index is never transmitted, but
regenerated locally on the receiving side).

But you can still run into problems if you are accessing the repo at the
filesystem level with two different versions (e.g., by mounting from a
remote server, or by copying your .git directory from machine to
machine).

For example (I keep many old git versions around as git.$version, but
in your case it would presumably happen on separate machines).

  # set up a simple repo with v1.7.0.2
  git.v1.7.0.2 init repo
  cd repo
  echo content >file
  git.v1.7.0.2 add file
  git.v1.7.0.2 commit -m foo
  git.v1.7.0.2 repack -ad

  # now try accessing with v1.2.4, which yields:
  # error: non-monotonic index
  # fatal: bad object ab929d107cceaf4d4b4d6a2d9b0aac275fd6e227
  git.v1.2.4 log

It can be fixed with:

  git.v1.7.0.2 config repack.useDeltaBaseOffset false
  git.v1.7.0.2 config pack.indexVersion 1
  git.v1.7.0.2 repack -ad
  # and now this works
  git.v1.2.4 log

where again, you would do the v1.7.0.2 bits on the machine with the
newer git.

Does this apply to your situation (two versions of git accessing the
same repo at the filesystem level)? If so, does setting that config and
repacking clear things up?

-Peff