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.
Related
For one of our repositories we set "Custom CI configuration path" inside GitLab to a remote gitlab-ci.yml. We want to do this to prevent Developers to change the gitlab-ci.yml file (as protected files are available in EE Premium and up). But except this purpose, the Custom CI configuration path feature should work anyway for Merge Requests.
Being in repo
group1/repo1
we set
.gitlab-ci.yml#group1/repo1-ci
repo1-ci repository exists and ci works correctly when we push to configured branches etc.
For Merge Request functionality GitLab tells us:
Detached merge request pipeline #123 failed for ...
Project group1/repo1-ci not found or access denied!
We added the developers to repo1-ci repo as developers, to be able to read the files. It does not help. Anyway the expectation is, that it is not run with user permissions, so it should simply find the gitlab-ci.yml file.
Any ideas on this?
So our expectations were right an it seems that we have to add one important thing into our considerations:
If a user interacts in the GitLab UI with the Merge Request features and you are using "Custom CI configuration path" for your gitlab-ci.yml file, please ensure
this user needs at least read permissions to that remote file, even if you moved it to another repo on purpose (e.g. use enhanced file protection in PREMIUM/ULTIMATE or push/merge protect the branches for the Developer role)
the user got this permission change applied in a running session
The last part failed for our users, as it worked one day later. Seems that they just continued working from their open merge request page and GitLab checks the accessibility out of this session (using a cookie, token or something which was not updated with the the access to the remote repo/file)
It works!
Say I've got an upstream repo (origin) that was added with
git remote add origin file:////upstream.host/repo.git
The repo.git is acually a windows shared folder where I and my dev colleagues have r/w access assigned.
Now, I want to set up a post-receive hook on upstream.host that notifies Trac about freshly pushed revisions for automatic ticket updating. Basically, this is done by calling an executable on upstream.host that does some work in the database there.
However, I notified that the hook for some reason doesn't work.
So I've set up the hook to print everything she's doing to D:/temp/post-receive.log and issued a git push in order to trigger the hook.
When I looked into D:/temp on upstream.host, there was no logfile created.
Then, another question of me came into mind: https://superuser.com/questions/974337/when-i-run-a-git-hook-in-a-repo-on-a-network-share-which-binaries-are-used.
When actually the binaries of my machine are used for executing the hook, maybe also the paths of my machine are used. I looked into D:/temp and voilá, here we have the post-receive.log.
I traced the pwd to the logfile and it is not D:/repos/repo.git (what I expected) but actually is //upstream.host/repo.git. Obviously the whole hook is executed in the context of the pusher's machine and not in the context of the repo machine (upstream.host).
This is no problem for me since I have admin access to the remote machine and could use administrative shares in order to get my hook going (i.e. \\upstream.host\D$\repos\repo.git etc). But this is an issue for my colleagues since they are plain users and no roots.
How do I set up my post-receive hook properly so that it works as expected?
How do I force my hook to be entirely run on the remote machine without using anything from my machine?
Do I really have to implement a real server hosting my repo? Or are there other ways that don't need a server?
a post-receive hook is run after receiving data on the machine that is hosting the repository.
now the machine that is "hosting the repository" is not the file-server where the actual packed-refs and other git database files are stored. (this file-server could be anything from a redundant cloud-based storage appliance to any old NAS-enabled "network disk").
Instead it is the machine that runs the "git frontend" (that is, the git commands that actually interact with the database).
Now you are using a "network share" to host your (remote) git repository. For your computer (the client), this is just another disk device (like your floppy) and the git on your client will happily store database-files there, and run any hooks. But this is your computer, since it is being told to run the remote locally - simply because the file:// protocol does mean "local".
Btw, the fact that your remote is named upstream.host is meaningless: this name is only there for you to keep track of multiple remotes, but it could be called thursday.next instead.
So there is no way to run any script on the file-server that happens to store some files names pack-refs and similar.
If you want to have a git server to run hooks for you, you must have a git server first. Even worse: if you want a git server on machineX to run scripts on machineX, you must install a git server on machineX first.
The good news: there is no need to "implement a real server". Just install a pre-existing one. You will find docuementation about that in the Git Book, but for starters it's basically enough to have git (for interaction with the database) and sshd (for secure communication via the network; and for calling git when appropriate) installed.
Finally: i'm actually quite glad that you need to have software (e.g. a server) running on the remote end to execute code there. Just imagine what it would mean if copying some html files to your USB disk would suddenly spawn a web server out of thin air. Not to think of w32-virusses breeding happily on my linux NAS...
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.
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.
We are a team of less than ten persons that need to quickly set up a git server that supports active directory based authentication.
The simplest solution seems to be to use a file share with a bare git repository and reaching it using a unc path, e.g.
git clone //server/share/repo.git
However, we are a bit worried about robustness. Are there no issues with concurrency when several people use the same git repository and there is no actual server component running?
Clients are running windows 7, server is Windows Server 2008R2. Using msysgit 1.8.1.2
(I am well aware that there are many other git server solutions, but, especially given the requirement of AD authentication, they are not as simple to set up)
It seems the only times the AR Auth will be in play is pushing/pulling.
When you clone the git repo, the entire history will be cloned as well, so every user will have a complete repo.
If the file share fails, any user can replace the code on a new share by pushing their code up.
Concurrency is not an issue - since git is distributed it handles concurrency differently from other VCSs: no file locks, etc.