Re: 6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch

From: Jeff King <peff@peff.net>
Date: Sep 28, 2011, 18:53 UTC
Message-ID: <20110928185327.GB1482@sigill.intra.peff.net>
In-Reply-To: <1317225869.30267.18.camel@bee.lab.cmartin.tk>

On Wed, Sep 28, 2011 at 06:04:27PM +0200, Carlos Martín Nieto wrote:

Show 10 quoted lines

> Whilst trying to do some work related to fetch, I came across a
> regression in the 'next' branch. Bisecting gave me this commit as
> breaking point (and I tried with the parent and there it worked). When
> doing 'git fetch', rev-list will complain about usage, and fetch will
> say that we didn't receive enough, even though earlier versions of git
> have no problems. This fails both on github and on git.or.cz and for git
> and http transports:
> 
> $ ./git-fetch git://repo.or.cz/git
> usage: git rev-list [OPTION] <commit-id>... [ -- paths... ]

Hmm. I notice you're running a not-installed version of fetch. Might this be a problem with a new git fetch running an older, installed version of rev-list?

The commit you mention calls rev-list with --verify-objects, but that feature is only added in the parent commit. So I can reproduce your issue with:

  $ git checkout 6d4bb38~2 ;# or anything before --verify-objects
  $ make install
  $ git checkout 6d4bb38
  $ make
  $ ./git-fetch git://repo.or.cz/git

but this works (because it sets the exec path properly):

  $ ./bin-wrappers/git fetch git://repo.or.cz/git

as does this:

  $ make install
  $ ./git-fetch git://repo.or.cz/git

So I don't think there's a bug. It's just that running compiled programs straight out of the build directory isn't supported. It works _most_ of the time, but as you can see, you may end up calling older, installed versions of git. The bin-wrappers scripts set up the exec path properly to let you test.

-Peff