* 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).