Breakage in master since 6d4bb3833c

When testing reference-handling performance using my refperf script [1], I noticed that there is a problem in master that I bisected down to

6d4bb3833c "fetch: verify we have everything we need before updating our ref"

When I run the following commands

======================================================= GIT=$(pwd)/git ORIG=bug-6d4bb383-repo REPO=bug-6d4bb383-clone URL=file://$(pwd)/$ORIG

$GIT init $ORIG cd $ORIG $GIT config gc.auto 0 $GIT config gc.packrefs false touch a.txt $GIT add a.txt $GIT commit -am 'Add file' cd ..

mkdir $REPO cd $REPO $GIT init $GIT remote add origin $URL $GIT fetch origin =======================================================

Then the last "git fetch origin" command gives the following output:

=======================================================
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
usage: git rev-list [OPTION] <commit-id>... [ -- paths... ]
  limiting output:
    --max-count=<n>
    --max-age=<epoch>
    --min-age=<epoch>
    --sparse
    --no-merges
    --min-parents=<n>
    --no-min-parents
    --max-parents=<n>
    --no-max-parents
    --remove-empty
    --all
    --branches
    --tags
    --remotes
    --stdin
    --quiet
  ordering output:
    --topo-order
    --date-order
    --reverse
  formatting output:
    --parents
    --children
    --objects | --objects-edge
    --unpacked
    --header | --pretty
    --abbrev=<n> | --no-abbrev
    --abbrev-commit
    --left-right
  special purpose:
    --bisect
    --bisect-vars
    --bisect-all
error: file:///home/mhagger/self/proj/git/git/bug-6d4bb383-repo did not
send all necessary objects

=======================================================

The same error occurs if all of the steps *except* the last one are done with a release version of git.

Michael

[1] branch "refperf" at git://github.com/mhagger/git.git

Hi,

On Fri, Oct 21, 2011 at 02:10:53PM +0200, Michael Haggerty wrote:

I suspect this is the same issue as here:

  http://thread.gmane.org/gmane.comp.version-control.git/182339/focus=182357

Best, Gábor

On 10/21/2011 02:28 PM, SZEDER Gábor wrote:

Yes, you are right.  Setting GIT=$(pwd)/bin-wrappers/git fixes the problem.

Thanks, Michael

Michael Haggerty <mhagger@alum.mit.edu> writes:

So in short, this was a false alarm crying wolf, and there was no problem?

On 10/21/2011 07:01 PM, Junio C Hamano wrote:

Correct, it was my fault for not running the locally-compiled version of git the correct way to get consistent invocation of subprocesses. So there was no problem.

...but there arguably *is* a metaproblem, namely that the obvious naive way to invoke a locally-compiled test version of git without installing it neither works correctly nor fails loudly. It sometimes works (if the main process doesn't need to call any subprocesses), sometimes works accidentally (if the subprocess that is used happens to have the behavior expected by the test version) and sometimes fails bizarrely (as in my case and other cases recently mentioned on the mailing list).

I can think of a few ugly hacks that could improve the situation:

1. Don't compile executables into the project root directory, but rather
into a subdirectory named something awful like
"do-not-run-commands-from-this-directory" with a big README.txt in the
directory explaining how the commands *should* be run.  Even knowing
that one has to RTFM would be a help.

2. Include a special file like "GIT-DEV-SETUP" in the directory to which
the executables are compiled, but don't copy this file to $BINDIR when
git is installed.  Teach git commands to check for the presence of
$(dirname $0)/GIT-DEV-SETUP, and if found, do the equivalent of "exec
GIT-DEV-SETUP "$@"" or maybe just read and use some values out of
GIT-DEV-SETUP to set up the correct environment.  There could be some
environment variable like GIT_SETUP_DONE to prevent recursion and/or
allow this step to be bypassed.

3. Have git commands tell git subcommands what version they are
expecting (either via an environment variable or via a hidden
command-line parameter), and have the subcommand barf if the version
does not match its own internal version.  This approach is more
intrusive but would also help defend against inconsistently-installed
versions (like having one version installed in /usr/bin and fragments of
another version installed in $HOME/bin).

Michael