* Bug on OS X...
@ 2013-06-27 10:17 John Szakmeister
2013-06-28 12:44 ` Max Horn
0 siblings, 1 reply; 6+ messages in thread
From: John Szakmeister @ 2013-06-27 10:17 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug on OS X...
2013-06-27 10:17 Bug on OS X John Szakmeister
@ 2013-06-28 12:44 ` Max Horn
2013-06-28 13:51 ` John Szakmeister
0 siblings, 1 reply; 6+ messages in thread
From: Max Horn @ 2013-06-28 12:44 UTC (permalink / raw)
To: John Szakmeister; +Cc: git
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug on OS X...
2013-06-28 12:44 ` Max Horn
@ 2013-06-28 13:51 ` John Szakmeister
2013-06-28 17:13 ` Junio C Hamano
0 siblings, 1 reply; 6+ messages in thread
From: John Szakmeister @ 2013-06-28 13:51 UTC (permalink / raw)
To: Max Horn; +Cc: git
On Fri, Jun 28, 2013 at 8:44 AM, Max Horn <max@quendi.de> 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@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 <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug on OS X...
2013-06-28 13:51 ` John Szakmeister
@ 2013-06-28 17:13 ` Junio C Hamano
2013-06-28 20:38 ` John Szakmeister
0 siblings, 1 reply; 6+ messages in thread
From: Junio C Hamano @ 2013-06-28 17:13 UTC (permalink / raw)
To: John Szakmeister; +Cc: Max Horn, git
John Szakmeister <john@szakmeister.net> writes:
> On Fri, Jun 28, 2013 at 8:44 AM, Max Horn <max@quendi.de> 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@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 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.
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?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug on OS X...
2013-06-28 17:13 ` Junio C Hamano
@ 2013-06-28 20:38 ` John Szakmeister
2013-06-28 20:51 ` Junio C Hamano
0 siblings, 1 reply; 6+ messages in thread
From: John Szakmeister @ 2013-06-28 20:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Max Horn, git
On Fri, Jun 28, 2013 at 1:13 PM, Junio C Hamano <gitster@pobox.com> wrote:
> John Szakmeister <john@szakmeister.net> writes:
>
>> On Fri, Jun 28, 2013 at 8:44 AM, Max Horn <max@quendi.de> 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@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 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug on OS X...
2013-06-28 20:38 ` John Szakmeister
@ 2013-06-28 20:51 ` Junio C Hamano
0 siblings, 0 replies; 6+ messages in thread
From: Junio C Hamano @ 2013-06-28 20:51 UTC (permalink / raw)
To: John Szakmeister; +Cc: Max Horn, git
John Szakmeister <john@szakmeister.net> writes:
> On Fri, Jun 28, 2013 at 1:13 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> 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! .... Turning on transfer.fsckObjects did indeed
> cause the issue to appear on Linux as well.
Good.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-06-28 20:51 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-27 10:17 Bug on OS X John Szakmeister
2013-06-28 12:44 ` Max Horn
2013-06-28 13:51 ` John Szakmeister
2013-06-28 17:13 ` Junio C Hamano
2013-06-28 20:38 ` John Szakmeister
2013-06-28 20:51 ` Junio C Hamano
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).