From Gitosis' point of view, your name is just the name, in keydir
, of the public key that you authenticated with. No configuration on your local machine matters, except as it affects what public key you use, and the string at the end of the key doesn't matter -- just the filename.
You've given your public key two names, so when you authenticate with that key it is undefined which one of them it finds when it looks for a name for that key. When you changed some other things in Gitosis, presumably it happened to change the arbitrary choice of which name it found.
(Specifically, I believe Gitosis generates its own authorized_keys
to contain all the keys in keydir
, one per line, with options to tell sshd
to only let the user run Gitosis, only in a controlled manner, and telling Gitosis the name of the key. If multiple lines have the same key, I'm not sure which one sshd
ends up using -- maybe the first, maybe the last, maybe it's arbitrary. The order in which Gitosis writes them may also be arbitrary. But really the details of how the arbitrary choice happens are beside the point, because nobody guarantees they won't change in the next update to sshd
or gitosis
.)
You should pick which name you want to use to refer to yourself in the Gitosis config, and keep in keydir
only the copy of your key under that name.
Using the example of my copy of Puppet checked out from the upstream Git repository on Github.com...
$ git remote show origin
* remote origin
Fetch URL: git://github.com/reductivelabs/puppet.git
Push URL: git://github.com/reductivelabs/puppet.git
HEAD branch: master
Remote branches:
0.24.x tracked
0.25.x tracked
2.6.x tracked
master tracked
next tracked
primordial-ooze tracked
reins-on-a-horse tracked
testing tracked
testing-17-march tracked
testing-18-march tracked
testing-2-april tracked
testing-2-april-midday tracked
testing-20-march tracked
testing-21-march tracked
testing-24-march tracked
testing-26-march tracked
testing-29-march tracked
testing-31-march tracked
testing-5-april tracked
testing-9-april tracked
testing4268 tracked
Local branch configured for 'git pull':
master merges with remote master
Local ref configured for 'git push':
master pushes to master (up to date)
Then if I were to execute the following:
$ git checkout -b local_2.6 -t origin/2.6.x
Branch local_2.6 set up to track remote branch 2.6.x from origin.
Switched to a new branch 'local_2.6'
And finally re-run the git remote show origin
command again I will then see the following down near the bottom:
Local branches configured for 'git pull':
local_2.6 merges with remote 2.6.x
master merges with remote master
Best Answer
After much trial and error, the following recipe was found to work:
true credit should go to drizzd on #git for this answer.