{"thread":{"id":"37618","subject":"Bug in git 2.1.0 when cloning to directory with same name as repository","startedAt":"2014-09-23T07:49:55Z","lastAt":"2014-09-23T08:39:03Z","messageCount":2,"participants":["Chris Salzberg","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"249768","messageId":"CAMoD=Bi41mB3QRn3JdZL-FGHs4w3C2jGpnJB-CqSndO7FMtfzA@mail.gmail.com","threadId":"37618","inReplyTo":null,"subject":"Bug in git 2.1.0 when cloning to directory with same name as repository","fromName":"Chris Salzberg","fromEmail":"csalzberg@degica.com","sentAt":"2014-09-23T07:49:55Z","receivedAt":"2014-09-23T07:49:55Z","isPatch":false,"sender":{"key":"csalzberg@degica.com","avatar":null},"body":"I've found what looks like a bug wherein if you are using an ssh alias\nfor a git remote, and that remote has a dash in its name, and you\nspecify the target path as the name of the url itself, git complains\nabout refs not being valid packed references.\n\nTo reproduce, in git 2.1.0 and with a repository using ssh config and\nwhich has a dash in the name, e.g.:\n\n> git clone github:nixme/pry-nav \"github:nixme/pry-nav\"\nCloning into 'github:nixme/pry-nav'...\ndone.\n  ror: internal error: refs/remotes/origin/master is not a valid\npacked reference!\nerror: internal error: refs/tags/v0.0.1 is not a valid packed reference!\nerror: internal error: refs/tags/v0.0.2 is not a valid packed reference!\nerror: internal error: refs/tags/v0.0.3 is not a valid packed reference!\nerror: internal error: refs/tags/v0.0.4 is not a valid packed reference!\nerror: internal error: refs/tags/v0.1.0 is not a valid packed reference!\nerror: internal error: refs/tags/v0.2.0 is not a valid packed reference!\nerror: internal error: refs/tags/v0.2.1 is not a valid packed reference!\nerror: internal error: refs/tags/v0.2.2 is not a valid packed reference!\nerror: internal error: refs/tags/v0.2.3 is not a valid packed reference!\nerror: internal error: refs/tags/v0.2.4 is not a valid packed reference!\nerror: Trying to write ref refs/heads/master with nonexistent object\nf0e17451f0bd508f408d4fdda97e3a131d11f696\nfatal: Cannot update the ref 'HEAD'\n\nThe ssh config for github (not that it matters, but for completeness) is:\n\nHost github\nuser git\nhostname github.com\n\nI have confirmed that if the repository url does not have a dash, this\nworks as expected. I have also downgraded to 2.0.4 and found that\nagain, this works as expected. Beyond this I have not narrowed the\nscope.\n\nFor now, I've downgraded my version of git and so have not tested beyond this.\n\nChris Salzberg\n"},{"id":"249776","messageId":"20140923083903.GA7644@peff.net","threadId":"37618","inReplyTo":"CAMoD=Bi41mB3QRn3JdZL-FGHs4w3C2jGpnJB-CqSndO7FMtfzA@mail.gmail.com","subject":"Re: Bug in git 2.1.0 when cloning to directory with same name as repository","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-09-23T08:39:03Z","receivedAt":"2014-09-23T08:39:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Sep 23, 2014 at 04:49:55PM +0900, Chris Salzberg wrote:\n\n> I've found what looks like a bug wherein if you are using an ssh alias\n> for a git remote, and that remote has a dash in its name, and you\n> specify the target path as the name of the url itself, git complains\n> about refs not being valid packed references.\n> \n> To reproduce, in git 2.1.0 and with a repository using ssh config and\n> which has a dash in the name, e.g.:\n\nThanks for a reproduction recipe. I think we can make it simpler,\nthough. The problem seems to come when your destination directory is\nidentical to the remote URL. I saw similar failures with:\n\n  git clone git@github.com:git/git git@github.com:git/git\n\nand even:\n\n  git clone https://github.com/git/git https://github.com/git/git\n\nIt bisects to f38aa83 (use local cloning if insteadOf makes a local URL,\n2014-07-17) by Michael Barabanov (cc'd). That commit moved a call to\nget_repo_path() much further down cmd_clone, after we have already\ncreated the repo directory. As a result, we try to fetch objects from\nthe newly created directory, which of course has none (and because it's\nlocal, we try to use \"cp\" instead of the git protocol. We don't notice\nthe error at transfer time, but rather later when trying to write out\nthe references).\n\nI'm not sure of the simplest solution. I guess along the lines of one\nof:\n\n  1. Move the code back before the directory is created. Rather than\n     using `remote_get` to apply insteadOf substitution as a side\n     effect, make it possible to call into the insteadOf code directly.\n\n  2. It might work to chdir() into the repo after creating it, though\n     that probably creates its own problems with other relative paths\n     (and I am not sure it would save us if you had a remote URL that\n     looked like an absolute path).\n\n-Peff\n"}]}