I wanted to look at some OpenWRT bits this morning and ran into an
issue cloning the packages repository when setting up the package
feed. The feeds script executes this under the hood:
git clone --depth 1 git://nbd.name/packages.git feeds/packages
When trying to run the command directly on OS X, I see:
:: git clone --depth 1 git://nbd.name/packages.git
Cloning into 'packages'...
remote: Counting objects: 4728, done.
remote: Compressing objects: 100% (4013/4013), done.
remote: Total 4728 (delta 158), reused 3339 (delta 94)
Receiving objects: 100% (4728/4728), 3.85 MiB | 1.79 MiB/s, done.
Resolving deltas: 100% (158/158), done.
error: unable to find 9f041557a0c81f696280bb934731786e3d009b36
fatal: object of unexpected type
fatal: index-pack failed
I tried on Linux, and it succeeded. I tested with both 1.8.2 and
1.8.3.1. Unfortunately, I don't have time to dig through what's wrong
at the moment so I thought I'd put it out there for others.
Thanks!
-John
On 27.06.2013, at 12:17, John Szakmeister wrote:
I wanted to look at some OpenWRT bits this morning and ran into an
issue cloning the packages repository when setting up the package
feed. The feeds script executes this under the hood:
git clone --depth 1 git://nbd.name/packages.git feeds/packages
When trying to run the command directly on OS X, I see:
:: git clone --depth 1 git://nbd.name/packages.git
Cloning into 'packages'...
remote: Counting objects: 4728, done.
remote: Compressing objects: 100% (4013/4013), done.
remote: Total 4728 (delta 158), reused 3339 (delta 94)
Receiving objects: 100% (4728/4728), 3.85 MiB | 1.79 MiB/s, done.
Resolving deltas: 100% (158/158), done.
error: unable to find 9f041557a0c81f696280bb934731786e3d009b36
fatal: object of unexpected type
fatal: index-pack failed
I tried on Linux, and it succeeded. I tested with both 1.8.2 and
1.8.3.1. Unfortunately, I don't have time to dig through what's wrong
at the moment so I thought I'd put it out there for others.
I am unable to reproduce this on Mac OS X 10.7.5 with git 1.8.3.1 nor with current git maint. Command run inside /tmp, which is on a normal HFS+ volume (using the default settings, i.e. the FS is case insensitive).
$ git --version
git version 1.8.3.1.42.ge2652c0
$ git clone --depth 1 git://nbd.name/packages.git
Cloning into 'packages'...
remote: Counting objects: 4711, done.
remote: Compressing objects: 100% (3998/3998), done.
remote: Total 4711 (delta 157), reused 3326 (delta 94)
Receiving objects: 100% (4711/4711), 3.85 MiB | 0 bytes/s, done.
Resolving deltas: 100% (157/157), done.
Cheers,
Max
On Fri, Jun 28, 2013 at 8:44 AM, Max Horn [off-list ref] wrote:
[snip]
I am unable to reproduce this on Mac OS X 10.7.5 with git 1.8.3.1 nor with current git maint. Command run inside /tmp, which is on a normal HFS+ volume (using the default settings, i.e. the FS is case insensitive).
$ git --version
git version 1.8.3.1.42.ge2652c0
$ git clone --depth 1 git://nbd.name/packages.git
Cloning into 'packages'...
remote: Counting objects: 4711, done.
remote: Compressing objects: 100% (3998/3998), done.
remote: Total 4711 (delta 157), reused 3326 (delta 94)
Receiving objects: 100% (4711/4711), 3.85 MiB | 0 bytes/s, done.
Resolving deltas: 100% (157/157), done.
OK, so I finally tracked it down. Commit
6035d6aad8ca11954c0d7821f6f3e7c047039c8f fixes it:
commit 6035d6aad8ca11954c0d7821f6f3e7c047039c8f
Author: Nguyễn Thái Ngọc Duy [off-list ref]
Date: Sun May 26 08:16:15 2013 +0700
fetch-pack: prepare updated shallow file before fetching the pack
index-pack --strict looks up and follows parent commits. If shallow
information is not ready by the time index-pack is run, index-pack may
be led to non-existent objects. Make fetch-pack save shallow file to
disk before invoking index-pack.
git learns new global option --shallow-file to pass on the alternate
shallow file path. Undocumented (and not even support --shallow-file=
syntax) because it's unlikely to be used again elsewhere.
Signed-off-by: Nguyễn Thái Ngọc Duy [off-list ref]
Signed-off-by: Junio C Hamano [off-list ref]
It looks like I was hitting the race condition. It's fixed on master,
so I assume it will be in 1.8.3.2.
Thanks for taking a look though!
-John