Ok I'm aware this sounds stupid and I'm actually stunned this is such a problem, I changed my account under linux before but in Windows it somehow doesn't work at all.
All I want is to use another account. I tried setting new account name etc.
git config --global ***
However, while it display the right name, when I try to push it still uses my old account.
I cant believe this is so hard and wasted already way too much time on it, could someone please enlighten me (I'd prefer using bash but whatever gets the job done is good).
And for some reason google only gives me crap on this...
git config --global -e for editing the config.
As specified by the command line:
-e, --edit open an editor
This only changes the display name. To change accounts, switch your SSH key identity or HTTP credentials.
all you're doing is setting your display name
Try this
git config credential.https://github.com.username yourusername
More info on the git documentation
Ok finally found an answer:
Go to Credential Manager
Go to Windows Credentials
Delete the entries under Generic Credentials
As described in this post:
Remove credentials from Git
Related
I am running Git on OSX Mavericks and have not had issues until now. What has changed is that I'm trying to use two Github accounts on different repos on the same computer.
The problem is that the osx-keychain is storing the login information from my first account. That was terrific before, but whenever I try to commit or push from my new Github account, it is defaulting to use the keychain's username and password values, and ignoring the locally-defined git config (or even global git config!) files.
I can delete my osx-keychain, and then push to the new account, but in doing so it will create a new keychain for that account, which puts me back at square one: able to push to my secondary account with the new keychain values but locked out of my primary account.
So I'm stuck in an "either-or" situation, and I'm really hoping there's a "both" solution. Any help?
P.S. I have tried this solution, and it did not work, as the osx-keychain appeared to override the SSH Identity functionality
If you are using https url, then the solution you mention wouldn't have any effect: it is for multiple ssh keys.
Regarding https, this question mentions a few solutions, including:
By default gitcredentials only considers the domain name.
If you want git to consider the full path (e.g. if you have multiple GitHub accounts), set the useHttpPath variable to true, as described at gitcredentials.
Note that changing this setting will ask your credentials again for each URL.
By default, Git does not consider the "path" component of an http URL to be worth matching via external helpers.
This means that a credential stored for https://example.com/foo.git will also be used for https://example.com/bar.git.
If you do want to distinguish these cases, set this option to true.
Also, make sure your https url incudes your account name:
git clone https://user1#github.com/auser/aprojectX
git clone https://user2#github.com/auser/aprojectY
That will help a credential helper to known which account/password it should be looking for.
Finally, the authentication you are using for accessing a git repo hosting service has nothing to do with:
git config (--global) user.name
That last config is only for setting the author associated with your local commits.
It is not for selecting the account used to access a remote hosting website.
I am very new to coding, I have actually just started learning how to through the use of video tutorials. Anyway one of the steps along the path of learning is setting up an account on GIT and linking this account to my ruby command prompt, where all the work I do is saved onto this app.
The problem I have run into is that, for some reason, after following the instructions of both GIT and the video tutorial I am not quite able to do the following step.
git push -u origin master
the error I get is:
warning: Permanently added to the RSA host key for IP address .....
Permission denied (publickey).
My best guess is there is an issue with being an administrator or something along those lines but I do not possess the knowledge to change that at the moment.
I would like to point out here that I am a windows user, I have seen a lot of "solutions" out there which simply dont work for me as they include commands like "sudo" or others which do not exist in the windows format, well at least not on mine as I have decided not to go through Cygwin.
Any help would be appreciated. Thanks in advance to who ever tries to help!
The issue is with your SSH public key. Somehow the git server is not able to recognize you and refuse to accept the code you pushed.
SSH keys are stored in ~/.ssh/. You should make sure there's one created. If there's one, then link it with your git server account, otherwise, create one and link it.
Checkout this tutorial on creating SSH keys: https://help.github.com/articles/generating-ssh-keys#platform-windows
Weeks ago (and in a fog), I needed to make some changes to something hosted at github. I was directed by someone-who-knows-more-than-me (SWKMTM) via phone on exactly what to type in order to configure, pull down, modify, push back and then activate things. Part of this involved issuing instructions to git that said I as SWKMTM.
Now that I've had time to learn a bit about git/github (as well as to recall my github login information), I've gone back and tried to substitute my identity for SWKMTM on my client machine (a la git config --global user.name and git config --global user.email). After doing this, I can perform the same update activities as before. However, I have yet to be prompted to enter my github password (i.e., there is NO request to enter my github password). I'm assuming that something has been cached identifying me as SWKMTM (and that I must've done something in the earlier fog that involved entering SWKMTM's github password) -- either locally or by implicitly sending my SSH public key.
I've searched around in vain for .*rc files and configuration directories for anything that resembles credentials that might be associated with SWKMTM (in hopes of dispatching said credentials and forcing git to prompt for new ones). I've similarly failed to find anything at github that might tell if there is some sort of aliasing for public keys (and how it might be purged).
I've also tried the advised "git config -l" for any credential helper and have found none.
How can I force github to forget that I've been masquerading as SWKMTM?
[sidenote: this is on MacOS with no indication in config files that credential-osxkeychain is used. Only after using GIT_TRACE=1 on a push was it obvious where the credentialing was stored.]
user.name and user.email have nothing to do with credentials, they are just strings that are put into each commit you make to store your authorship information.
Git normally authenticates you via SSH, so you have to either copy your SSH private key from the other machine to your new client, or create a new key pair and add the public part to your github profile.
OK, after extensive discussion in the chat it turns out that Git was using the osxkeychain credential helper which provided previously stored credentials.
Remove your stored credentials from your OSX keychain or disable the crendential helper (credential.helper config option) in Git to be prompted for authentication again.
I'm trying to add a new remote repository (GitHub) to an existing project, and I'm getting an error that I've never seen before, and don't understand:
$ git remote add github git#github.com:me/myrepo.git
error: could not commit config file .git/config
What? Why would I commit the git config file? And how do I make this stop happening?
I'm on a Mac, with a relatively fresh install of most of my tools. I think this is the first time I've tried to add a remote to a repo on this machine.
Some git commands modify the git config file. One of them is git remote add, because the remote is stored in the config file.
To avoid problems with several git processes modifying the config file simultaneously, git will lock the config file before changing it (by writing a lock file), and release the lock afterwards (by renaming the lock file to the config file).
The error message
error: could not commit config file .git/config
means that git could not properly release this lock. This probably means that either another process was working on the same file, or there was some kind of filesystem error (or there's a bug in git or your OS/libraries).
Unfortunately, git does not tell you what exactly was the problem, so you'll have to manually debug this. You could try running git with dtruss to see what exactly is going wrong.
This could be a permissions issue, especially for automated jobs running on Windows that can have fewer permissions than an interactive login of the same user. From this answer on ServerFault:
Each logon session to a Windows (NT-based versions, that is) machine
has a "security token"-- a data structure that describes, amongst
other things, the groups that the user represented by the token is a
member of.
The "Interactive" identity isn't a group that you can manually place
members into, but rather is added by the operating system,
automatically, when a security token is constructed for a user who has
logged-on via the Windows Graphical User Interface. This is similar to
the "Network" identity, which is added automatically to tokens created
for users who are accessing the machine via the network.
These automatically-generated group memberships allow you to construct
permissions that might allow or deny access to resources based on how
the user is accessing the machine. This supplements the permission
system's default behavior of arbitrating access based on who is
accessing the resource.
Recently I am facing problem of commit to SVN. The SVN server I am using is VisualSVN Server 2.5.9 and the client is TortoiseSVN 1.7.12.
At first, one user is having problem to commit files to SVN. But that user still can access to the repository and download the update. The second user on second PC is working properly. But today, the second user is having the same problem as the first user.
Why is this happen? How can the problem be solved? Thanks.
If the problem lies client side, this could be one of the causes of the error.
On clients TortoiseSVN saves client credentials under
Tortoise settings / saved data / authentication data.
I got the same error trying to commit my files, but my credentials were changed. Clearing this cache here will give you a popup on next commit attempt for re-entering your correct credentials.
You can get the "Forbidden" error if your user account lacks access permissions to a repository or repository path; it makes sense to check authorization settings for your user account. Make sure your system administrator hasn't provided you with No Access permission to the repository path.
If you are sure that permissions are set correctly, then double-check the URL you use. URLs in Apache Subversion are case-sensitive.
Additionally, I advise you to read articles on authorization in Subversion and VisualSVN Server:
SVNBook about path-based authorization.
VisualSVN Team's article about path-based authorization. It explains the principles of SVN authorization by comparing it with Windows Access Control.
The solution for me was to check the case sensitivity of the username. A lot of people are mentioning that the URL is case sensitive, but it seems the username is as well!
As a new user to these two software packages, I experienced the exact same problem. As was also discovered above, my solution was to use the same case letters as is in the Repository path.
Here's a tip that I find helpful: In VisualSVN, you can right click on the path, then click "Copy URL to Clipboard" for pasting in Tortoise to be sure that the path is the identical case.
Actually, I had this problem same as you.
My windows is server 2008 and my subversion info is :
TortoiseSVN 1.7.6, Build 22632 - 64 Bit , 2012/03/08 18:29:39
Subversion 1.7.4,
apr 1.4.5
apr-utils 1.3.12
neon 0.29.6
OpenSSL 1.0.0g 18 Jan 2012
zlib 1.2.5
I used this way and I solved this problem.
I used [group] option. this option makes problem.
I rewrite authz file contents.
I remove group option. and I set one by one.
I use well.
Thanks for reading.
Actually, I had this problem same as you. You can get the "Forbidden" error if your commit includes different directories ; Like external items.
And ı solved in one step. Just commit external items in another case.
Additionally, I advise you to read articles on External Items in Subversion and VisualSVN Server:
VisualSVN Team's article about Daily Use Guide External Items. It explains the principles of External Items in SVN.
https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-externals.html
I had a similar issue in Mac where svn was picking mac login as user name and I was getting error as
svn: E170013: Unable to connect to a repository at URL 'https://repo:8443/svn/proj/trunk'
svn: E175013: Access to '/svn/proj/trunk' forbidden
I used the --username along with svn command to pass the correct username which helped me.
Alternatively, you can delete ~/.subversion/auth file, after which svn will prompt you for username.
I was unable to commit csharp-files (*.cs). In the end the problem was that at some point i installed mod_mono, which made the *.cs-files inaccessible, through its configuration. So it may well be an apache-configuration issue, if only some sort of files are not accessible.
grep ".cs" /etc/apache2/mods-enabled/*
...
mod_mono_auto.conf:AddType application/x-asp-net .cs
...
My issue was my SVN permissions.
I had the same problem "Access to '/svn/[my path]/!svn/me' forbidden" when trying to commit files to a project I had been working on daily for several months. After trying the steps above, I could not resolve the issue. I also tried pulling the project down from scratch, logging in/out of SVN, etc. Finally I contacted my company's IT department and there was a permissions issue that spontaneously emerged which changed my access from read/write to read-only access. The IT department refreshed my permissions and this solved the problem.