On Fri, Jun 28, 2013 at 1:13 PM, Junio C Hamano <gits...@pobox.com> wrote:
> John Szakmeister <j...@szakmeister.net> writes:
>> 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
>>> 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
>>> $ 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
>> ...
>> It looks like I was hitting the race condition.  It's fixed on master,
>> so I assume it will be in
> 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.

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

Reply via email to