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. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html