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

> On Wed, Sep 28, 2011 at 06:04:27PM +0200, Carlos Martín Nieto wrote:
> 
> > 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.