unable to get type of object

unable to get type of object

[Robert Garrigos]

I'm having one of those nasty 128 errors which I cannot debug:

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

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.

I would appreciate any help.

Thanks
-- 

Robert Garrigós
Tf. 607 997 973
http://garrigos.cat

Re: unable to get type of object

[Jakub Narebski]

Robert Garrigos <robert@garrigos.cat> writes:

> I'm having one of those nasty 128 errors which I cannot debug:
> 
> ************
> 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.
> 
> 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.

Do this repository uses submodules?  IIRC pre 1.4.x (or even later)
git didn't understand modules.

Or it might be problem with deltabaseoffset, i.e. when objects is
stored in pack as a difference (delta) from other objects, it refers
to base by offset in pack, and not by sha-1 id.  I don't remember if
ancient 1.2.4 supports this feature.  This is more likely.

Why don't you upgrade git (perhaps installing it locally in your home
directory)?
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: unable to get type of object

[Robert Garrigos]

Al 01/06/11 11:39, En/na Jakub Narebski ha escrit:
> Robert Garrigos<robert@garrigos.cat>  writes:
>
>> I'm having one of those nasty 128 errors which I cannot debug:
>>
>> ************
>> 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.
>>
>> 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.
> Do this repository uses submodules?  IIRC pre 1.4.x (or even later)
> git didn't understand modules.
>
> Or it might be problem with deltabaseoffset, i.e. when objects is
> stored in pack as a difference (delta) from other objects, it refers
> to base by offset in pack, and not by sha-1 id.  I don't remember if
> ancient 1.2.4 supports this feature.  This is more likely.
>
> Why don't you upgrade git (perhaps installing it locally in your home
> directory)?
Upgrading doesn't depend on me, unfortunately.

The problem arouse when creating a first branch and merging later into 
master branch. Does this give a clue?
-- 

Robert Garrigós
Tf. 607 997 973
http://garrigos.cat

Re: unable to get type of object

[Jeff King]

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

Re: unable to get type of object

[Tomas Carnecky]

On 6/1/11 6:04 PM, Jeff King wrote:
> On Wed, Jun 01, 2011 at 09:11:07AM +0200, Robert Garrigos wrote:
>> 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.

When looking through the last git survey I was wondering why there were 
people still using pre 1.3.x versions. Here we finally meet one of them :)

v1.2.4 was released March 1, 2006. It has about 48k lines of code, while 
master today has ~287k (counted using sloccount).

tom