Git pushing to remote GitHub repository as wrong user


I have a work GitHub account and a personal one. First I used the personal one for test projects, then I moved on and did a repository with the other account on the same computer.

Now I wanted to create a new repository on my personal account again, I changed the global and local, and did a new ssh key pair, entered in the GitHub setup page. Then I set up the directory

git init
git remote add origin <url>
git push origin

but that now tells me

ERROR: Permission to personaluser/newrepo.git denied to

I have no idea how the other account is connected to this one. .git/config shows no workusername related things.


Go to Control Panel > User Accounts > Credential Manager > Generic Credentials

remove the git credentials. Then run git push. This will prompt to ask for the git credentials. Enter your correct credentials.


Username and password in command for git push


It’s possible to clone down a git repository, specifying username and password in the command. Example:

git clone

Is it is possible to also specify the username and password when pushing? So that, for example, running git push origin --all will then output asking for a password. I want this in one command.

(I am aware of the ability to set up keys and other solutions, but I want to know if there is a way to just keep using username and password with one command.) I am running Git Bash on Windows 8.1.


Yes, you can do

git push --all

in this case replace the origin in git push origin --all

To see more options for git push, try git help push


git pushes with wrong user from terminal


I have an issue with git and my terminal.

Here’s a gallery to show you my issue :

When I push commits from my terminal, git says I push them with another username, that’s a user from my organisation (my company) with no commit at all and it seems it belongs to no one : (check gallery first pic)

But this doesn’t happen when I use Github for mac, in the feed I see the commits pushed by myself.

The problem also affects my personal repositories, my terminal says that I don’t have the permission to push commits on those repositories (which is obviously wrong) since it tries to push it with this user : (check gallery second pic)

Guess what ? This doesn’t happen with Github for mac too.

I changed my computer to a brand new one few days ago, so I reset’ed all my ssh key of github and left only a new one generated by Github for Mac so I don’t think that there’s some ghost user/ssh key hidden somewhere, this hdd is brand new : (check gallery third pic)

My .gitconfig file is all clear, there’s only my credentials : (check gallery fourth pic)

I really don’t get it, help, StackOverflow, you’re my only hope.

(My apologies for my poor Gimp skills and the Star Wars reference)

EDIT : ssh-add -l only shows the good ssh key created by github for mac and I have only one github account

EDIT2 : ssh -T recognize me as the good user.

EDIT3 : After a few tests it looks like my terminal does the commits with my username, but pushes them with the other one, Github for mac commits and pushes with the good username.This situation happen with every repo I have/make (even new ones).

EDIT4 : In a personal repository git log --pretty="%h %an %ae" shows my good username

EDIT5 : No sign of environment variables that would override my credentials in my env. Even if I try to set those variables with the good credentials problem persists.

EDIT6 : Things work back normally if I force the user in the path of /.git/config of a repository but I don’t think that’s the good option :

EDIT7 : We deleted the git user that pushed the commits for me and this brings another error : remote: Invalid username or password. fatal: Authentication failed for ''

FINAL EDIT : I installed git with homebrew, typed git config --global push.default simpleand now it takes my credentials even without forceing the user. That’s strange. Thanks everybody for your help, you’re great guys !


check ~/.gitconfig and $project_root/.git/config files. One of those two is surely misconfigured for user name. – mu 無 Feb 6 ’14 at 22:31

Despite all the great options given by other users, the only way to fix this was to reinstall git completely and type git config --global push.default simple to rewrite good credentials.


git config --system --unset credential.helper worked for me, I’m now asked for my GitHub credentials on push again and can supply the correct user ID and password. – CoDEmanX Sep 2 ’16 at 12:44



In this post, I’m going to cover some basics for using Visual Studio’s Git support with Github repositories.  Specifically, I’ll cover

  • Pre-Requisites (getting setup).
  • Forking a Repository
  • Cloning a Repository
  • Committing Changes to a Local Repository
  • Pushing Changes to a Remote Repository
  • Submitting Pull Requests


I’m going to be use Visual Studio 2013 Preview because it’s new and it comes pre-packaged with Git support.  So, no additional downloads are needed.  If you want to do the things I’m going to show in this post using Visual Studio 2012, then you will need the Visual Studio Tools for Git .

The other pre-requisite is a Github account .


Suppose you have found a Github repository that interests you and you want to make some contributions.  You could ask the repository owner to give you access to the repository so you can make changes.  That’s likely to be met with a firm “NO” if you get any response at all.  Or, you could essentially copy the repository to a repository under your Github account where you can make all the changes you want to your own copy.  That’s what forking a repository basically does.  It sets up a copy in your Github account that you can work against.  It also provides a way to link back to the repository you forked from so you can offer your great work back to the original repository owners for consideration (see Submitting Pull Requests below).

Github provides a repository called “Spoon-Knife” that is available for demonstration purposes, which I will use to demonstrate the concepts in this post.  Assume I want to make some contributions to this repository.  Once I’m logged into Github and have navigated to the “Spoon-Knife” repository, I can click the Fork button to fork the repository.


After a few seconds, I have a copy of this repository sitting in my Github account.  Notice the link back to the repository I forked from at the top.  Also, notice the HTTPS clone URL in the lower-right corner.  This will be needed for the next section.



To clone a repository is to get a local copy of it on your development machine.  This will allow you to commit changes to the local repository in the absence of any connectivity to the remote repository on Github.  This is a key difference between distributed and centralized version control systems.

From Visual Studio’s Team Explorer, clicking on the Connect button will show the available repositories you can connect to.


Since I’m working from a fresh install, I don’t have any repositories yet.  I’ll clone the remote repository by clicking the Clone link.


Adding the HTTPS clone URL from the remote repository to the address field and clicking the Clone button will bring a copy of the repository local.


Now, in the future, when I open Team Explorer, I’ll see this repository in my Local Git Repositories.


It’s not really complicated what’s happening here.  If you open Windows Explorer and navigate to the folder shown above, you can see it’s simply a copy of the remote repository on Github.  If you look closely, you will also see a “.git” folder.  That’s where Git stores information about the local repository as you work with it.  You should leave it alone.  However, I wanted to call it out as an artifact of cloning the remote repository.



Now I’m ready to start making some contributions to this repository.  Suppose I want to add a new project.  I’ll start by creating a new project and setting the Location to the path of my local repository.


Clicking OK will create the project in the folder of my local repository.  Switching over to Team Explorer and clicking on Changes


… will show all the folders and files for the project I just created as Included Changes.  This doesn’t mean that the changes have been committed yet.  It just means that Visual Studio and Git are aware of them and tracking the changes.


To commit the changes I need to enter a commit message and click the Commit button.


Now this is committed to my local repository.  Note, this is not committed to my remote repository on Github.  I’ll get to that in the next section.


It is not necessary that changes/contributions come just from Visual Studio.  For example, suppose I want to add some user instructions for the HelloWorld project.  I can simply create a file in the folder of the local repository.


Now, going back to Team Explorer, I can see in the Untracked Files section that Visual Studio and Git are aware of this new file, but not tracking it.  To start tracking this file, right-click on the file and select Add.


Now, this file is being tracked as a change to my local repository.  However, it has still not been committed to the repository.


To commit this change, I’ll add a comment and click the Commit button just as I demonstrated earlier.

So far, I’ve made two commits to my local repository.  I can view these commits and drill into the details for each by clicking on the Commits link.


My two commits are in the Outgoing Commits section.  From here, I can double-click into these commits to review the details for each.


Before I move onto the next section, I want to revisit the Untracked Files from earlier.


Here, the tools are rightfully assuming you don’t want to add these files to version control.  Generally, you only want source code in the repository and not the compiled artifacts that land in directories like bin\Debug and obj\Debug.  Nor do you want your Visual Studio user options file committed to the repository.  You can tell Git to ignore these by right-clicking on the folder and selecting ignore.  This will result in a .gitignore file being added to your local repository so these will be ignored going forward.


You also have the option of deleting the Untracked Files.  This will physically delete the files from the repository folder on disk.  However, next time you build the application, they will be recreated and show back up as Untracked Files.


Eventually you will need to get your changes in the local repository up to your remote repository on Github.  That’s what a push does.  When you initiate a push, your local repository is checked against the remote repository to see if any changes were added that you don’t have locally.  If so, then you will need to resolve those conflicts locally before you can push to the remote repository.  Since my remote repository is mine and only mine, I won’t have any conflicts.  But, imagine if you were on a team with other developers, all committing changes to the same remote repository.  In this case, your local repository is likely to get out of sync with the remote repository.  In which case, you will need to resolve these conflicts before pushing to the remote repository.

Using Team Explorer, you can Fetch or Pull commits from the remote repository.  A Fetch will return back a list of commits without applying the changes to your local repository.  This gives you an opportunity to review changes from other users before proceeding.  A Pull will apply the changes in the remote repository to your local repository, potentially prompting you to resolve any conflicts.


Once your local repository is in sync with the remote repository, clicking the Push link under Outgoing Commits will push your commits up to the remote repository.  When the push is completed, Incoming Commits and Outgoing Commits will be empty.  In other words, your local repository and remote repository are in sync.


Now, if I go back to the remote repository on Github, I can see these commits have been applied.


Near the top of the page is a commits link.  Drilling into this will show details for the commits. In the Commits page, you can further drill into the changes to see what files were added/modified.



Up until now, all the changes I’ve made have been to my local and remote repository that I forked from “octocat/Spoon-Knife” repository.  Suppose now I want to offer up my great work to the owners of the “octocat/Spoon-Knife” repository.  The way this is done is through a Pull Request.  A pull request is a request to the original repository owner to pull my changes into the original repository.  If accepted, then my changes become part of the original repository I forked from.  Later, if I or someone else were to fork the “octocat/Spoon-Knife” repository, my contributions would be there.

To submit a pull request, I’ll click the Pull Requests link on the right-hand side of the screen.


This takes me to a screen where I can view all my pull requests.  Since I’ve not submitted one yet, I don’t have any to view.  On this screen is a New pull request button I can click on to submit a new one.


This takes me to a screen that shows all the details for the pull request I’m about to submit.


Once I confirm this is what I want to do, then I can click on the Click to create a pull request for this comparison link.  This will take me to a screen where I can give a title and some brief comments for the pull request.


Clicking the Send pull request button will submit my pull request and take me to the original “octocat/Spoon-Knife” repository.  That’s it – done!  What generally will follow from here is some back-and-forth collaboration, code reviews, changes, bug fixes, etc.



If you’re a new contributor to a repository, then you may want to spend some time reviewing the pull requests of the original repository your forked from.  You can do this by going to the repository on Github.


On the right-hand side of the screen is a Pull Requests link.  Clicking this will take me to a screen where I can see the 583 other pull requests that people have submitted.  In a real development repository, this is a good way to see who’s actively making contributions and also to observe things such as the kinds of pull requests the repository owners are accepting.  This gives some insight into coding standards that may be expected.  For example, if you UPPERCASE all your variable names while the repository owners prefer camelCase, then you can expect comments from the owners to change your casing before they will accept it.


There are many other things I’ve not touched on in this blog post, such as branching, reverting commits, etc.  Perhaps I’ll talk about that in another post.  This post is long enough as it is though and covers the basics – which was my goal.

There is plenty of good documentation to learn about Git, Github, and key differences between centralized anddistributed version control systems.  Here is a handy link that links to some additional reading on the subject.

Unable to clone Git repository due to self signed certificate



Git server is using self signed certificate and FishEye/Crucible unable to clone the Git repository.

The following appears in the atlassian-fisheye-<date>.log:

2013-07-02 18:15:48,400 WARN  [InitialPinger2 ] fisheye IndexingPingRequest-doRequest - Exception during FishEye Incremental Indexing of Gitrepo: com.cenqua.fisheye.config.ConfigException: Unable to clone remote repository: https://fisheyeuser@git.server:8443/scm/test/gitrepo.git
 - [fatal: unable to access 'https://fisheyeuser:XXXX@git.server:8443/scm/test/gitrepo.git/': SSL certificate problem: self signed certificate in certificate chain]
 - Cloning into bare repository 'clone'...


Git client in FishEye/Crucible server perform verification on the SSL certificate and stop the process if it is unknown.


Disable Git SSL verification in the server hosting FishEye/Crucible with the following commands:

git config --global http.sslVerify false


1. Import the Git server self signed certificate into FishEye/Crucible server according to PKIX Path Building Failed - Cannot Set Up Trusted Applications To SSL Services
2. Configure the Git client in FishEye/Crucible server to refer to the cacerts that have the imported certificate: 

git config --system http.sslCAPath /path/to/cacerts

3. Restart FishEye/Crucible server

How can I make git accept a self signed certificate?

[Originally posted by]:

To permanently accept a specific certificate, try http.sslCAPath or http.sslCAInfo. Adam Spiers’s answer gives some great examples. This is the most secure solution to the question.

To disable TLS/SSL verification for a single git command, try passing -c to git with the proper config variable, or use Flow’s answer:

git -c http.sslVerify=false clone

To disable SSL verification for that singular repository, assuming it’s completely under your control, you can try:

git config http.sslVerify false

Disabling TLS(/SSL) certificate verification globally is a terribly insecure practice. Don’t do it. Do not issue the above command with a --global modifier.

There are quite a few SSL configuration options in git. From the man page of git config:

    Whether to verify the SSL certificate when fetching or pushing over HTTPS.
    Can be overridden by the GIT_SSL_NO_VERIFY environment variable.

    File containing the certificates to verify the peer with when fetching or pushing
    over HTTPS. Can be overridden by the GIT_SSL_CAINFO environment variable.

    Path containing files with the CA certificates to verify the peer with when
    fetching or pushing over HTTPS.
    Can be overridden by the GIT_SSL_CAPATH environment variable.

A few other useful SSL configuration options:

    File containing the SSL certificate when fetching or pushing over HTTPS.
    Can be overridden by the GIT_SSL_CERT environment variable.

    File containing the SSL private key when fetching or pushing over HTTPS.
    Can be overridden by the GIT_SSL_KEY environment variable.

    Enable git's password prompt for the SSL certificate. Otherwise OpenSSL will
    prompt the user, possibly many times, if the certificate or private key is encrypted.
    Can be overridden by the GIT_SSL_CERT_PASSWORD_PROTECTED environment variable.