On Tue, Sep 23, 2014 at 04:49:55PM +0900, Chris Salzberg wrote: > I've found what looks like a bug wherein if you are using an ssh alias > for a git remote, and that remote has a dash in its name, and you > specify the target path as the name of the url itself, git complains > about refs not being valid packed references. > > To reproduce, in git 2.1.0 and with a repository using ssh config and > which has a dash in the name, e.g.: Thanks for a reproduction recipe. I think we can make it simpler, though. The problem seems to come when your destination directory is identical to the remote URL. I saw similar failures with: git clone git@xxxxxxxxxx:git/git git@xxxxxxxxxx:git/git and even: git clone https://github.com/git/git https://github.com/git/git It bisects to f38aa83 (use local cloning if insteadOf makes a local URL, 2014-07-17) by Michael Barabanov (cc'd). That commit moved a call to get_repo_path() much further down cmd_clone, after we have already created the repo directory. As a result, we try to fetch objects from the newly created directory, which of course has none (and because it's local, we try to use "cp" instead of the git protocol. We don't notice the error at transfer time, but rather later when trying to write out the references). I'm not sure of the simplest solution. I guess along the lines of one of: 1. Move the code back before the directory is created. Rather than using `remote_get` to apply insteadOf substitution as a side effect, make it possible to call into the insteadOf code directly. 2. It might work to chdir() into the repo after creating it, though that probably creates its own problems with other relative paths (and I am not sure it would save us if you had a remote URL that looked like an absolute path). -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