Git pushing to remote GitHub repository as wrong user

[Origin]: https://stackoverflow.com/questions/13103083/how-do-i-push-to-github-under-a-different-username

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 user.name, 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.

git permissions github

shareedit

edited Jun 29 ’14 at 1:40 user456814

asked Jan 12 ’11 at 4:28 Raz Faz 291143

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.

shareedit

answered Jan 31 at 21:53 Rajan Patil 48339

Username and password in command for git push

[Origin]: https://stackoverflow.com/questions/29776439/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 https://username:password@myrepository.biz/file.git

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.

git git-bash

shareedit

asked Apr 21 ’15 at 15:20 Jake 1,0412826

Yes, you can do

git push https://username:password@myrepository.biz/file.git --all

in this case https://username:password@myrepository.biz/file.git replace the origin in git push origin --all

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

shareedit

answered Apr 21 ’15 at 15:28 number5 8,58813544

git pushes with wrong user from terminal

[Origin]: http://stackoverflow.com/questions/21615431/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 : http://imgur.com/a/6RrEY

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 git@github.com 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 : http://USER@github.com/USER/REPO.git

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 'https://github.com/USER/REPO.git/'

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 !

git github ssh

shareedit

edited Feb 7 ’14 at 13:24

asked Feb 6 ’14 at 22:27 Yinfei 2061311

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.

shareedit

answered Mar 12 ’14 at 8:35 Yinfei 2061311

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

VISUAL STUDIO AND GITHUB: THE BASICS OF WORKING WITH EXISTING REPOSITORIES

[Origin]: http://rickrainey.com/2013/07/27/visual-studio-and-gitub-the-basics-of-working-with-existing-repositories-2/

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

PRE-REQUISITES

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 .

FORKING A REPOSITORY

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.

CLONING A REPOSITORY

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.

COMMITTING CHANGES TO A LOCAL 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.

PUSHING CHANGES TO A REMOTE REPOSITORY

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.

SUBMITTING PULL REQUESTS

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.

CONSIDERATIONS BEFORE SUBMITTING PULL REQUESTS

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.

CONCLUSION

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

[Origin]: https://confluence.atlassian.com/bitbucketserverkb/resolving-ssl-self-signed-certificate-errors-806029899.html

Symptoms

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'...

Cause

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

Workaround

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

git config --global http.sslVerify false

Resolution

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]: http://stackoverflow.com/questions/11621768/how-can-i-make-git-accept-a-self-signed-certificate

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 https://domain.com/path/to/git

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:

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

http.sslCAInfo
    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.

http.sslCAPath
    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:

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

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

http.sslCertPasswordProtected
    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.

shareedit

edited Aug 17 ’15 at 19:01

answered Jul 23 ’12 at 23:28 Christopher 16.6k44561

Easy way pull latest of all submodules

http://stackoverflow.com/questions/1030169/easy-way-pull-latest-of-all-submodules

For git 1.6.1 or above you can use something similar to (modified to suit):

git submodule foreach git pull origin master

See git-submodule(1) for details

shareedit

edited Aug 13 at 7:24 Rudolf Adamkovic 7,82033958

answered Jun 23 ’09 at 13:42 Henrik Gustafsson 15.2k53152

Driving Git With Emacs – Pure Magic With Magit – Part One

http://jr0cket.co.uk/2012/12/driving-git-with-emacs-pure-magic-with.html.html

Getting to grips with Git was not to much of a learning curve, although I found it quicker to work on the command line than using graphical tools. Using git status and git log made it easy to keep a handle on my code changes.

As I do most of my Clojure development in Emacs, it was great to discover I could drive git from Emacs using Magit. What follows is a flow through the first steps with Magit.

In part two I look at Git logs with Magit

I use Emacs Live from Sam Aaron as my Emacs configuration (Emacs 24 from Emacs for MacOSX), so the packages andkey-bindings mentioned here are all available in this configuration unless otherwise stated.

Getting started

I start a new Clojure project using Leiningen, using the command line to do so. Instead of having a seperate terminal window for this, I can open up a command line shell window in Emacs

M-x eshell

I then navigate to my projects folder using `cd ~/projects/clojure and then create a new Clojure project using Leiningen, the build automation tool for Clojure.

lein new project-name

I could continue to use the terminal to manage the git repository, although once I got used to magit then using git inside Emacs seems more natural.

Using eshell, you can also easily open files using find-filefilenameand see all the files and folders usingdired folder`. So lets see what Leiningen has created for us

dired project-name

You can use the mouse or cursor to open any file listed, or navigate to sub-folders. In this case lets select the Leiningen project configuration file, project.clj.

Initialising a repository in git

Now I have a Clojure project, I can put that project under git version control

M-x magit-init

The emacs mini-buffer will prompt you for the top level folder of the files you want to version with git. If you are still in the top level project folder in the shell, magit-init will pick up the path, saving you some typing.

You will now be able to see the .git folder inside your project directory.

Git Status in Emacs

The most commonly used git command is git status – showing you what files have changes, which are staged, untracked files, pending commits and remote updates. To see the git status of your project in Emacs

M-x magit-status

Short-cut key-binding: C-x g

Keyboard shortcuts are defined in ~/emacs.d/packs/dev/bindings-pack/config/default-bindings.el

(global-set-key (kbd "C-x g") 'magit-status)

You will be prompted for the location of the git repository (the one you just created). Magit does a good job of guessing the folder assuming you already have a file open that is somewhere in a folder hierachy that has a .git folder in it.

With a newly versioned project then there will not be that much to see, except all the files not yet put under version control (untracked files).

The Local: line show the branch you are working on (master) and location of your project.

The Head: line shows you the last commit you made to your repository.

Staging changes

To version control your files you need to tell git about them. This is done by staging the files using the git addcommand. You can add individual files or all files that are untracked. Using magit, this is even easier.

In the magit-status buffer in Emacs, you can use the following key shortcuts to stage and unstage files

s – stage a specific untracked file highlighted by cursor (stage all untracked files when cursor over Untracked files title)

k – delete a specific untracked file highlighted by cursor (delete all untracked files when cursor over “Untracked files” title). See Delete really deletes section below.

i – add file to the project .gitignore file

u – unstage a specific staged change highlighted by cursor

C-u s – stages everything – tracked and untracked changes (Note: this failed when I tried it)

Under the hood

Using the $ key opens another buffer that shows you the command happening when you press keys in the magit-status window. Its a handy way to learn the command syntax and confirm magit is doing what you expected.

Note: All the files matching pattern in the project .gitignore or personal ~/.gitignore_global files will not be shown as untracked files.Delete really deletes

Using the k command in magit-status really deletes the local file, so be sure that is what you want. You get a prompt in the mini-buffer to confirm the delete though.

Testing this delete out, I noticed that not only was the file deleted but so was the folder that contained the file. As you can see in the dired my-project buffer, the doc folder has gone. If you delete files then this buffer may need a refresh, using g.

Committing your changes

Before you make too many changes you should commit them to your local repository. The more commits you make the smaller and easier they will be to mange.

On the command line you would run git commit -m "useful commit message", from the magit-status buffer its much easier:

c

This pops up another buffer for you to type in your commit message. Once you have typed your message then C-c C-c commits all the changes to your local repository. C-c C-k cancels the commit.

Now all our staged files have been added as a commit to our local repository. We can see this by looking at the Head: line in the magit-status window. We can also see that there are no changes (tracked or otherwise) shown.

Working with a remote Github repository

Assuming we have created a repository on Github it can be added as a remote source very easily

M-x magit-add-remote

You are prompted for the name you want to give the remote, origin, upstream or github are common names depending on your context. The name acts as an alias for the address of the Github repository, so keep it short but meaningful.

Now you are prompted for the Internet address of your repository. On the Github website your repository name is shown at the top of the page. Use the SSH version of the address, the one that starts git@github:....

Magit will now add the remote name and address to the project .git/config file.

You can now push your local commits up to Github using the key: P

The first time you press P the push menu appears.

Pressing P again pushes to the remote repository.

And there is more magit

There is a lot more you can do with magit, next up is Git logs with Magit.

If you are really keen you can have a look at the Magit documentation, or if you know what you want to do then theMagit cheet sheet may be more useful.

Magit not cutting the mustard ?

For situations when Magit doesn’t do everything you need, you can run raw Git commands using : (colon). This will prompt for a Git command, run it, and refresh the status buffer. The output can be viewed by typing $.

Thank you.

How to cancel a local git commit

http://stackoverflow.com/questions/4850717/how-to-cancel-a-local-git-commit

Just use git reset without the --hard flag:

git reset HEAD~1

PS: On Unix based systems you can use HEAD^ which is equal to HEAD~1. On Windows HEAD^ will not work because ^ signals a line continuation. So your command prompt will just ask you More?.

shareedit

edited Jul 10 at 18:42 awilkinson 340316

answered Jan 31 ’11 at 12:17 Koraktor 11.5k33566