0

I'm trying to adapt Specify an SSH key for git push for a given domain to my problem. The difference in my case is that I don't want to push to multiple domains, but always to the same domain as multiple (Git) users from one (Unix) account.

~/.ssh/config is set up to have an entry for each user:

Host git-as-bob
  HostName git.domain.tld
  User git
  IdentityFile /home/shared/.ssh/id_rsa-bob
  IdentitiesOnly yes

Host git-as-alice
  HostName git.domain.tld
  User git
  IdentityFile /home/shared/.ssh/id_rsa-alice
  IdentitiesOnly yes

In one repository, I've made the necessary changes, and pushing works just fine (note: saying just git push is supposed not to work, that's what the first command is for. It wouldn't much matter though, because the default pubkey only has read access to the repositories).

$ git remote set-url --push origin no_push
$ git remote add origin-bob git@git-as-bob:/repository1.git
$ git remote add origin-bob git@git-as-bob:/repository1.git

Here, the following happens:

$ git push origin-bob master
Everything up-to-date

In a second repository, I did the exact same thing, but the outcome is different:

$ git push origin-bob master
To git@git-as-bob:/repository2.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'git@git-as-bob:/repository2.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Note that git remote -v returns virtually the same in both cases (i.e., the only difference is "repository1.git" vs. "repository2.git". Note also that prior to pushing, both repositories were in sync with origin. In the example shown here, there wasn't actually anything to push, but if there is, the same problem shows up.

If this is a sound approach, how could I troubleshoot it? If it is not, what would be the appropriate way of going about such a setup?

Community
  • 1
  • 1
Sixtyfive
  • 1,150
  • 8
  • 19
  • The error you've shown suggests that someone else has pushed before you got there. Have you tried pulling before pushing to see what is there? – merlin2011 Oct 02 '15 at 00:10
  • @merlin2011: Yes. I'm in full control of these repositories (meaning that for the time being, noone else except me uses them). I even tried `rm -rf`'ing the directories and `git clone`'ing them again. Doesn't change anything. – Sixtyfive Oct 02 '15 at 00:54

1 Answers1

1

I even tried rm -rf'ing the directories and git clone'ing them again. Doesn't change anything.

That would indeed change nothing: that rejection error is because of the content on the remote side.
If you are in full control of those repos (and have the right history in your local repo), the fastest way to resolve the situation is a:

git push --force origin-bob master

You will then have the same history on your remote repo.

The OP Rainer Verteidiger adds in the comments:

It turned out I had a mistake in adding some but not all of the new remotes.
After done right, it all works just the way I did it.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Hmm, I don't think I understand why it would be like that. If I make a completely fresh clone of a repo, are the remote repo and the new local repo not *by definition* in sync then? Or put differently: why does the cloning produce an "out of sync" repo? `git remote set-url --push origin no_push` and `git remote add origin-bob git@git-as-bob:/repository1.git` don't count as "changes", or do they? – Sixtyfive Oct 02 '15 at 08:00
  • @RainerVerteidiger I agree. Without seeing the log on both local and remote repo, I wouldn't know. Which is why I just gave the quickest way to rectify the situation. – VonC Oct 02 '15 at 08:01
  • So it turned out I had a mistake in adding *some* but not *all* of the new remotes. After done right, it all works just the way I did it. If there had actually been a problem, I think your answer would have been the most sensible one like you said. Thanks! – Sixtyfive Oct 02 '15 at 21:41
  • @RainerVerteidiger Great! I have included your comment in the answer for more visibility. – VonC Oct 03 '15 at 05:26