{"thread":{"id":"28522","subject":"6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch","startedAt":"2011-09-28T16:04:27Z","lastAt":"2011-10-01T10:54:05Z","messageCount":9,"participants":["Carlos Martín Nieto","Junio C Hamano","Jeff King","Jakub Narebski","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"176429","messageId":"1317225869.30267.18.camel@bee.lab.cmartin.tk","threadId":"28522","inReplyTo":null,"subject":"6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2011-09-28T16:04:27Z","receivedAt":"2011-09-28T16:04:27Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"Hello,\n\nWhilst trying to do some work related to fetch, I came across a\nregression in the 'next' branch. Bisecting gave me this commit as\nbreaking point (and I tried with the parent and there it worked). When\ndoing 'git fetch', rev-list will complain about usage, and fetch will\nsay that we didn't receive enough, even though earlier versions of git\nhave no problems. This fails both on github and on git.or.cz and for git\nand http transports:\n\n$ ./git-fetch git://repo.or.cz/git\nusage: git rev-list [OPTION] ... [ -- paths... ]\n limiting output:\n --max-count=\n --max-age=\n --min-age=\n --sparse\n --no-merges\n --min-parents=\n --no-min-parents\n --max-parents=\n --no-max-parents\n --remove-empty\n --all\n --branches\n --tags\n --remotes\n --stdin\n --quiet\n ordering output:\n --topo-order\n --date-order\n --reverse\n formatting output:\n --parents\n --children\n --objects | --objects-edge\n --unpacked\n --header | --pretty\n --abbrev= | --no-abbrev\n --abbrev-commit\n --left-right\n special purpose:\n --bisect\n --bisect-vars\n --bisect-all\nerror: git://repo.or.cz/git did not send all necessary objects\n"},{"id":"176445","messageId":"7vsjngzelc.fsf@alter.siamese.dyndns.org","threadId":"28522","inReplyTo":"1317225869.30267.18.camel@bee.lab.cmartin.tk","subject":"Re: 6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-28T18:50:07Z","receivedAt":"2011-09-28T18:50:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlos Martín Nieto writes:\n\n> Whilst trying to do some work related to fetch, I came across a\n> regression in the 'next' branch....\n>\n> $ ./git-fetch git://repo.or.cz/git\n\nThat invocation of ./git-fetch looks suspicious.\n\nAre you sure that it internally invokes ./git-rev-list from the same\nversion that knows --verify-objects option (you just built in your current\ndirectory), or is it invoking an old git-rev-list that is installed and is\nreachable from your usual $PATH, which does not know that option yet?\n\nWhen I try a new version that was just built in my current directory, here\nis an incantation I use:\n\n GIT_EXEC_PATH=`pwd`\n PATH=`pwd`:/usr/bin:/bin\n GITPERLLIB=`pwd`/perl/blib/lib\n\n export GIT_EXEC_PATH PATH GITPERLLIB\n"},{"id":"176446","messageId":"20110928185327.GB1482@sigill.intra.peff.net","threadId":"28522","inReplyTo":"1317225869.30267.18.camel@bee.lab.cmartin.tk","subject":"Re: 6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-09-28T18:53:28Z","receivedAt":"2011-09-28T18:53:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Sep 28, 2011 at 06:04:27PM +0200, Carlos Martín Nieto wrote:\n\n> Whilst trying to do some work related to fetch, I came across a\n> regression in the 'next' branch. Bisecting gave me this commit as\n> breaking point (and I tried with the parent and there it worked). When\n> doing 'git fetch', rev-list will complain about usage, and fetch will\n> say that we didn't receive enough, even though earlier versions of git\n> have no problems. This fails both on github and on git.or.cz and for git\n> and http transports:\n> \n> $ ./git-fetch git://repo.or.cz/git\n> usage: git rev-list [OPTION] ... [ -- paths... ]\n\nHmm. I notice you're running a not-installed version of fetch. Might\nthis be a problem with a new git fetch running an older, installed\nversion of rev-list?\n\nThe commit you mention calls rev-list with --verify-objects, but that\nfeature is only added in the parent commit. So I can reproduce your\nissue with:\n\n $ git checkout 6d4bb38~2 ;# or anything before --verify-objects\n $ make install\n $ git checkout 6d4bb38\n $ make\n $ ./git-fetch git://repo.or.cz/git\n\nbut this works (because it sets the exec path properly):\n\n $ ./bin-wrappers/git fetch git://repo.or.cz/git\n\nas does this:\n\n $ make install\n $ ./git-fetch git://repo.or.cz/git\n\nSo I don't think there's a bug. It's just that running compiled programs\nstraight out of the build directory isn't supported. It works _most_ of\nthe time, but as you can see, you may end up calling older, installed\nversions of git. The bin-wrappers scripts set up the exec path properly\nto let you test.\n\n-Peff\n"},{"id":"176449","messageId":"m3y5x8o527.fsf@localhost.localdomain","threadId":"28522","inReplyTo":"1317225869.30267.18.camel@bee.lab.cmartin.tk","subject":"Re: 6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-09-28T19:12:28Z","receivedAt":"2011-09-28T19:12:28Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Carlos Martín Nieto writes:\n\n> Hello,\n> \n> Whilst trying to do some work related to fetch, I came across a\n> regression in the 'next' branch. Bisecting gave me this commit as\n> breaking point (and I tried with the parent and there it worked). When\n> doing 'git fetch', rev-list will complain about usage, and fetch will\n> say that we didn't receive enough, even though earlier versions of git\n> have no problems. This fails both on github and on git.or.cz and for git\n> and http transports:\n> \n> $ ./git-fetch git://repo.or.cz/git\n\nHave you tried\n\n $ ./git fetch git://repo.or.cz/git\n\n?\n\n-- \nJakub Narębski\n"},{"id":"176612","messageId":"1317426491.4331.23.camel@centaur.lab.cmartin.tk","threadId":"28522","inReplyTo":"20110928185327.GB1482@sigill.intra.peff.net","subject":"Re: 6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2011-09-30T23:48:10Z","receivedAt":"2011-09-30T23:48:10Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Wed, 2011-09-28 at 14:53 -0400, Jeff King wrote:\n> On Wed, Sep 28, 2011 at 06:04:27PM +0200, Carlos Martín Nieto wrote:\n> \n> > Whilst trying to do some work related to fetch, I came across a\n> > regression in the 'next' branch. Bisecting gave me this commit as\n> > breaking point (and I tried with the parent and there it worked). When\n> > doing 'git fetch', rev-list will complain about usage, and fetch will\n> > say that we didn't receive enough, even though earlier versions of git\n> > have no problems. This fails both on github and on git.or.cz and for git\n> > and http transports:\n> > \n> > $ ./git-fetch git://repo.or.cz/git\n> > usage: git rev-list [OPTION] ... [ -- paths... ]\n> \n> Hmm. I notice you're running a not-installed version of fetch. Might\n> this be a problem with a new git fetch running an older, installed\n> version of rev-list?\n\nYes, this seems indeed to be the case.\n\n> \n> The commit you mention calls rev-list with --verify-objects, but that\n> feature is only added in the parent commit. So I can reproduce your\n> issue with:\n> \n> $ git checkout 6d4bb38~2 ;# or anything before --verify-objects\n> $ make install\n> $ git checkout 6d4bb38\n> $ make\n> $ ./git-fetch git://repo.or.cz/git\n> \n> but this works (because it sets the exec path properly):\n> \n> $ ./bin-wrappers/git fetch git://repo.or.cz/git\n> \n> as does this:\n> \n> $ make install\n> $ ./git-fetch git://repo.or.cz/git\n> \n> So I don't think there's a bug. It's just that running compiled programs\n> straight out of the build directory isn't supported. It works _most_ of\n> the time, but as you can see, you may end up calling older, installed\n> versions of git. The bin-wrappers scripts set up the exec path properly\n> to let you test.\n\nIndeed, as both you and Junio pointed out (within three minutes of each\nother :) I was running git from the build directory and expected it to\nwork, as I was testing a few changed I had made to the fetch code.\n\nMea culpa, I tend to forget that git tends to behave like a bunch of\nshell scripts that happen to be written in C. Thanks to both.\n\n cmn\n\n\n"},{"id":"176613","messageId":"1317426849.4331.29.camel@centaur.lab.cmartin.tk","threadId":"28522","inReplyTo":"m3y5x8o527.fsf@localhost.localdomain","subject":"Re: 6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2011-09-30T23:54:08Z","receivedAt":"2011-09-30T23:54:08Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Wed, 2011-09-28 at 12:12 -0700, Jakub Narebski wrote:\n> Carlos Martín Nieto writes:\n> \n> > Hello,\n> > \n> > Whilst trying to do some work related to fetch, I came across a\n> > regression in the 'next' branch. Bisecting gave me this commit as\n> > breaking point (and I tried with the parent and there it worked). When\n> > doing 'git fetch', rev-list will complain about usage, and fetch will\n> > say that we didn't receive enough, even though earlier versions of git\n> > have no problems. This fails both on github and on git.or.cz and for git\n> > and http transports:\n> > \n> > $ ./git-fetch git://repo.or.cz/git\n> \n> Have you tried\n> \n> $ ./git fetch git://repo.or.cz/git\n\nBut this would execute /usr/local/libexec/git-fetch, wouldn't it? That\nis precisely what I don't want to execute, because I changed some code\nin builtin/fetch.c that I want to test.\n\nBut yes, the problem was that the local git-fetch was trying to pass an\noption to rev-list that my older installed binary didn't understand. In\nthis particular case I don't want to run the older git-fetch, but\notherwise, that would work.\n\nI guess I'll have to either properly install git from 'next' or base my\nchanged on 'maint'\n\n cmn\n\n\n"},{"id":"176625","messageId":"20111001060353.GA25228@sigill.intra.peff.net","threadId":"28522","inReplyTo":"1317426849.4331.29.camel@centaur.lab.cmartin.tk","subject":"Re: 6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-10-01T06:03:53Z","receivedAt":"2011-10-01T06:03:53Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Oct 01, 2011 at 01:54:08AM +0200, Carlos Martín Nieto wrote:\n\n> > Have you tried\n> > \n> > $ ./git fetch git://repo.or.cz/git\n> \n> But this would execute /usr/local/libexec/git-fetch, wouldn't it? That\n> is precisely what I don't want to execute, because I changed some code\n> in builtin/fetch.c that I want to test.\n\nNo, but only because fetch is a builtin. However, it still doesn't set\nup exec_path correctly, so your rev-list problem would not go away.\n\n> I guess I'll have to either properly install git from 'next' or base my\n> changed on 'maint'\n\nJust use bin-wrappers/git. That's exactly what it's there for (and it's\nwhat the test scripts use to make sure we are testing what is compiled).\n\nYour change isn't the problem; only your testing method.\n\n-Peff\n"},{"id":"176630","messageId":"BED2B875AEDF4E52843F1C9211A8D2A1@PhilipOakley","threadId":"28522","inReplyTo":"20111001060353.GA25228@sigill.intra.peff.net","subject":"Re: 6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2011-10-01T10:38:08Z","receivedAt":"2011-10-01T10:38:08Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Jeff King\" \n> On Sat, Oct 01, 2011 at 01:54:08AM +0200, Carlos Martín Nieto wrote:\n>\n>> > Have you tried\n>> >\n>> > $ ./git fetch git://repo.or.cz/git\n>>\n>> But this would execute /usr/local/libexec/git-fetch, wouldn't it? That\n>> is precisely what I don't want to execute, because I changed some code\n>> in builtin/fetch.c that I want to test.\n>\n> No, but only because fetch is a builtin. However, it still doesn't set\n> up exec_path correctly, so your rev-list problem would not go away.\n>\n>> I guess I'll have to either properly install git from 'next' or base my\n>> changed on 'maint'\n>\n> Just use bin-wrappers/git. That's exactly what it's there for (and it's\n> what the test scripts use to make sure we are testing what is compiled).\n>\n> Your change isn't the problem; only your testing method.\n>\n> -Peff\n\nPeff,\n\nIs there a write up of the the git testing method and how to use \nbin-wrappers etc. I didn't see anything in the Documentation, but I may not \nhave looked carefully enough\n\nPhilip \n"},{"id":"176631","messageId":"20111001105405.GA4396@sigill.intra.peff.net","threadId":"28522","inReplyTo":"BED2B875AEDF4E52843F1C9211A8D2A1@PhilipOakley","subject":"Re: 6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-10-01T10:54:05Z","receivedAt":"2011-10-01T10:54:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Oct 01, 2011 at 11:38:08AM +0100, Philip Oakley wrote:\n\n> Is there a write up of the the git testing method and how to use\n> bin-wrappers etc. I didn't see anything in the Documentation, but I\n> may not have looked carefully enough\n\nBin-wrappers (and the alternative, which is setting up the exec-path\nyourself) are mentioned briefly in INSTALL. Running tests is described\nin t/README.\n\nOther than that, you're left on your own to read the code and the commit\nmessages. :)\n\n-Peff\n"}]}