On Fri, Jun 28, 2013 at 8:44 AM, Max Horn <m...@quendi.de> wrote: [snip] > I am unable to reproduce this on Mac OS X 10.7.5 with git 220.127.116.11 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 18.104.22.168.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 <pclo...@gmail.com> 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 <pclo...@gmail.com> Signed-off-by: Junio C Hamano <gits...@pobox.com> It looks like I was hitting the race condition. It's fixed on master, so I assume it will be in 22.214.171.124. Thanks for taking a look though! -John -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html