{"thread":{"id":"28735","subject":"Breakage in master since 6d4bb3833c","startedAt":"2011-10-21T12:10:53Z","lastAt":"2011-10-22T05:11:20Z","messageCount":5,"participants":["Michael Haggerty","SZEDER Gábor","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"178120","messageId":"4EA1614D.3090202@alum.mit.edu","threadId":"28735","inReplyTo":null,"subject":"Breakage in master since 6d4bb3833c","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2011-10-21T12:10:53Z","receivedAt":"2011-10-21T12:10:53Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"When testing reference-handling performance using my refperf script [1],\nI noticed that there is a problem in master that I bisected down to\n\n6d4bb3833c \"fetch: verify we have everything we need before updating our\nref\"\n\nWhen I run the following commands\n\n=======================================================\nGIT=$(pwd)/git\nORIG=bug-6d4bb383-repo\nREPO=bug-6d4bb383-clone\nURL=file://$(pwd)/$ORIG\n\n$GIT init $ORIG\ncd $ORIG\n$GIT config gc.auto 0\n$GIT config gc.packrefs false\ntouch a.txt\n$GIT add a.txt\n$GIT commit -am 'Add file'\ncd ..\n\nmkdir $REPO\ncd $REPO\n$GIT init\n$GIT remote add origin $URL\n$GIT fetch origin\n=======================================================\n\nThen the last \"git fetch origin\" command gives the following output:\n\n=======================================================\nremote: Counting objects: 3, done.\nremote: Total 3 (delta 0), reused 0 (delta 0)\nUnpacking objects: 100% (3/3), done.\nusage: git rev-list [OPTION] <commit-id>... [ -- paths... ]\n  limiting output:\n    --max-count=<n>\n    --max-age=<epoch>\n    --min-age=<epoch>\n    --sparse\n    --no-merges\n    --min-parents=<n>\n    --no-min-parents\n    --max-parents=<n>\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=<n> | --no-abbrev\n    --abbrev-commit\n    --left-right\n  special purpose:\n    --bisect\n    --bisect-vars\n    --bisect-all\nerror: file:///home/mhagger/self/proj/git/git/bug-6d4bb383-repo did not\nsend all necessary objects\n\n=======================================================\n\nThe same error occurs if all of the steps *except* the last one are done\nwith a release version of git.\n\nMichael\n\n[1] branch \"refperf\" at git://github.com/mhagger/git.git\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"178121","messageId":"20111021122801.GA3799@goldbirke","threadId":"28735","inReplyTo":"4EA1614D.3090202@alum.mit.edu","subject":"Re: Breakage in master since 6d4bb3833c","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2011-10-21T12:28:01Z","receivedAt":"2011-10-21T12:28:01Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"Hi,\n\nOn Fri, Oct 21, 2011 at 02:10:53PM +0200, Michael Haggerty wrote:\n> When testing reference-handling performance using my refperf script [1],\n> I noticed that there is a problem in master that I bisected down to\n> \n> 6d4bb3833c \"fetch: verify we have everything we need before updating our\n> ref\"\n> \n> When I run the following commands\n> \n> =======================================================\n> GIT=$(pwd)/git\n\n> $GIT fetch origin\n> Then the last \"git fetch origin\" command gives the following output:\n> remote: Counting objects: 3, done.\n> remote: Total 3 (delta 0), reused 0 (delta 0)\n> Unpacking objects: 100% (3/3), done.\n> usage: git rev-list [OPTION] <commit-id>... [ -- paths... ]\n\nI suspect this is the same issue as here:\n\n  http://thread.gmane.org/gmane.comp.version-control.git/182339/focus=182357\n\n\nBest,\nGábor\n"},{"id":"178128","messageId":"4EA17B1D.9000900@alum.mit.edu","threadId":"28735","inReplyTo":"20111021122801.GA3799@goldbirke","subject":"Re: Breakage in master since 6d4bb3833c","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2011-10-21T14:01:01Z","receivedAt":"2011-10-21T14:01:01Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 10/21/2011 02:28 PM, SZEDER Gábor wrote:\n> On Fri, Oct 21, 2011 at 02:10:53PM +0200, Michael Haggerty wrote:\n>> When testing reference-handling performance using my refperf script [1],\n>> I noticed that there is a problem in master that I bisected down to\n>>\n>> 6d4bb3833c \"fetch: verify we have everything we need before updating our\n>> ref\"\n>>\n>> When I run the following commands\n>>\n>> =======================================================\n>> GIT=$(pwd)/git\n> \n>> $GIT fetch origin\n>> Then the last \"git fetch origin\" command gives the following output:\n>> remote: Counting objects: 3, done.\n>> remote: Total 3 (delta 0), reused 0 (delta 0)\n>> Unpacking objects: 100% (3/3), done.\n>> usage: git rev-list [OPTION] <commit-id>... [ -- paths... ]\n> \n> I suspect this is the same issue as here:\n> \n>   http://thread.gmane.org/gmane.comp.version-control.git/182339/focus=182357\n\nYes, you are right.  Setting GIT=$(pwd)/bin-wrappers/git fixes the problem.\n\nThanks,\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"178130","messageId":"7vehy68ejp.fsf@alter.siamese.dyndns.org","threadId":"28735","inReplyTo":"4EA17B1D.9000900@alum.mit.edu","subject":"Re: Breakage in master since 6d4bb3833c","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-10-21T17:01:14Z","receivedAt":"2011-10-21T17:01:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty <mhagger@alum.mit.edu> writes:\n\n> Yes, you are right.  Setting GIT=$(pwd)/bin-wrappers/git fixes the problem.\n\nSo in short, this was a false alarm crying wolf, and there was no problem?\n"},{"id":"178158","messageId":"4EA25078.8060501@alum.mit.edu","threadId":"28735","inReplyTo":"7vehy68ejp.fsf@alter.siamese.dyndns.org","subject":"Re: Breakage in master since 6d4bb3833c","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2011-10-22T05:11:20Z","receivedAt":"2011-10-22T05:11:20Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 10/21/2011 07:01 PM, Junio C Hamano wrote:\n> Michael Haggerty <mhagger@alum.mit.edu> writes:\n> \n>> Yes, you are right.  Setting GIT=$(pwd)/bin-wrappers/git fixes the problem.\n> \n> So in short, this was a false alarm crying wolf, and there was no problem?\n\nCorrect, it was my fault for not running the locally-compiled version of\ngit the correct way to get consistent invocation of subprocesses.  So\nthere was no problem.\n\n...but there arguably *is* a metaproblem, namely that the obvious naive\nway to invoke a locally-compiled test version of git without installing\nit neither works correctly nor fails loudly.  It sometimes works (if the\nmain process doesn't need to call any subprocesses), sometimes works\naccidentally (if the subprocess that is used happens to have the\nbehavior expected by the test version) and sometimes fails bizarrely (as\nin my case and other cases recently mentioned on the mailing list).\n\nI can think of a few ugly hacks that could improve the situation:\n\n1. Don't compile executables into the project root directory, but rather\ninto a subdirectory named something awful like\n\"do-not-run-commands-from-this-directory\" with a big README.txt in the\ndirectory explaining how the commands *should* be run.  Even knowing\nthat one has to RTFM would be a help.\n\n2. Include a special file like \"GIT-DEV-SETUP\" in the directory to which\nthe executables are compiled, but don't copy this file to $BINDIR when\ngit is installed.  Teach git commands to check for the presence of\n$(dirname $0)/GIT-DEV-SETUP, and if found, do the equivalent of \"exec\nGIT-DEV-SETUP \"$@\"\" or maybe just read and use some values out of\nGIT-DEV-SETUP to set up the correct environment.  There could be some\nenvironment variable like GIT_SETUP_DONE to prevent recursion and/or\nallow this step to be bypassed.\n\n3. Have git commands tell git subcommands what version they are\nexpecting (either via an environment variable or via a hidden\ncommand-line parameter), and have the subcommand barf if the version\ndoes not match its own internal version.  This approach is more\nintrusive but would also help defend against inconsistently-installed\nversions (like having one version installed in /usr/bin and fragments of\nanother version installed in $HOME/bin).\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"}]}