Egor Ryabkov <egor.ryabkov@xxxxxxxxx> writes: >>> "$ GIT_TRACE=1 git fetch" gives somewhat different output on local PC >>> and server: >>> http://pastecode.com/bd3fc1a79f8e9d1eaf30911d9895938051c472f4 >> ... > Did you imply that it's better to paste logs directly in the email? No, I did not *imply* it; it just didn't "click" that the above was a URL to a pastebin. > ############# AWS results ############# > > $ GIT_TRACE=1 git fetch > trace: built-in: git 'fetch' > trace: run_command: 'ssh' 'git@xxxxxxxxxx' 'git-upload-pack > '\''(username)/(reponame).git'\''' > ERROR: Repository not found. > fatal: The remote end hung up unexpectedly Assuming that these "(REDACTED)" are not hiding some crucial difference between the two destinations, it seems to be the git client installed on the latter one seems to be the one that is at fault. But as I said, "ERROR: Repository not found." does not seem to match any message of the released version of Git, so I cannot even tell where it is failing. It could be that the message is coming from a customized version of ssh login handler github uses to shard and map the user accounts to directories (it would have said "fatal: '/var/tmp/xx' does not appear to be a git repository" if they were running the vanilla Git), and if that is the case, perhaps the argument thrown at git-upload-pack from your local box and the problematic box somehow look different to Github, but that is in the "(REDACTED)" part, so I cannot tell from what was pasted in the pastebin. Incidentally, oogling [github "ERROR: Repository not found."] seems to give quite a many hits. -- 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