On Fri, Jun 28, 2013 at 1:13 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> John Szakmeister <john@xxxxxxxxxxxxxxx> writes:
>
>> On Fri, Jun 28, 2013 at 8:44 AM, Max Horn <max@xxxxxxxxx> 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 <pclouds@xxxxxxxxx>
>> Date: Sun May 26 08:16:15 2013 +0700
>>
>> fetch-pack: prepare updated shallow file before fetching the pack
>> ...
>> 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.
>
> Hmmmph, I do not think the cited change is about any "race".
>
> If it were that we spawn index-pack and write updated shallow
> information at the same time, and depending on the timings,
> index-pack may not read the updated one and fail, then it would have
> been a "race", but that is not the above change is about. If you
> saw the issue on MacOS, you would have seen the same breakage, as
> long as you started from the same repository status, on other
> platforms, and reliably.
Hmmm, that's what the message seemed to say to me (that it was racy).
> An early part of nd/clone-connectivity-shortcut topic contains the
> said commit, and I do not mind merging it to the maintenance track,
> but I suspect that there is something else going on on your OS X
> box, if you saw differences between platforms.
>
> Perhaps on your OS X box you have {transfer,fetch}.fsckobjects set
> to true while on others it is set to false, or something?
Good suggestion! I have a gitconfig that I propagate to many of the
machines I use, but I had not updated the Linux machine I was testing
with. Turning on transfer.fsckObjects did indeed cause the issue to
appear on Linux as well.
-John
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html