Can't deal with lock file .git-credentials.lock when exec git push in v2.8.3 #766
Comments
|
I am experiencing the same issue: |
|
I am not a fan of bug reports that simply delete the carefully-crafted issue reporting template, and then go on and make it hard for me by not providing anything resembling a Minimal, Complete & Verifiable Example. It's almost as if you wanted to make my life miserable. |
|
I had git 2.8.2 installed, and updated to git 2.8.3 using your installer. I'm running Windows 10 Pro, 64 bit.
Then the aforementioned error occurs. |
|
@dscho I update my issue. |
|
Is the crucial bit the credential store? If so, why did you not include it in the MCVE? I guess it is rather important. As it is, I spent all the time that I can afford this week on this ticket, to get only this far. Frustrating. |
|
I encountered this same issue following the same steps as @jnsn . Downgrading back to 2.8.2 solves it for me though |
|
@svermeulen Could you please provide an MCVE that I can really verify here? |
|
@dscho, the problem is indeed related to the As you can see, even though it throws an assertion error, the repository is successfully cloned. The error occurs with any other command which requires authenticating to the remote repository. When using the |
Note that the default helper is now Git Credential Manager. This example also overwrites any configuration, which is not good.
It would have been nice to specify one. As it happens, you can abuse GitHub for this, by pretending to clone a private repository. Take e.g. https://github.com/git/its-a-secret. However, I cannot reproduce the problem. For me, even if I configure things as you said, the Git Credential Manager pops up and it does not show an Assertion. I guess there is still a missing puzzle piece. |
|
The I can see in my $HOME folder that there's a Since I only have access to my company's private repositories, I can't link them. However, I was able to reproduce the issue with a public repository, which requires authentication when pushing. The next bit is interesting. At this point, if I check my Git config, I can see that the credential helper shows up twice: I did a search on my system and found that there's a I don't know if that file is a remnant of an old installation, or something that gets shipped with every installation. I continue with my operation: Interestingly, since both credential helpers are specified, I first get the default Windows UI prompting for my GitHub credentials, next I have to fill in my username at the command line and I get the old Git password prompt dialog. When entering my credentials, the error message is shown, but the push continues. |
|
@jnsn: the When you executed It would appear that your system configuration is set to use the Git Credentials Manager for Windows--which is to be expected because that's what Git for Windows comes with and that what gets installed (again, since 2.7.3). But your global or local settings are set to use the old credential helper, and I suspect it's in your global settings since you just cloned the repository. From the Git-Scm book:
This appears to have some resemblance to what's happening in your case--you have multiple helpers defined and it appears that they are being tried in turn. A few outstanding questions in my mind are:
|
|
FWIW this is an MCVE: printf 'protocol=https\nhost=gitblub.com\nusername=hello\npassword=world\n' |
git credential-store store |
<TODO> This fixes git-for-windows#766 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
@WhyEvenTry did you notice the commit mentioned earlier? If so, you can try it. The benefit would be that I know whether this fixes the bug and could make sure that the next Git for Windows release has the fix. |
In no released version yet. I require proof that the patch fixes the bug before I include it in any official release. I would consider any other course of action irresponsible. If you could build Git from my credstore-assertion branch and verify that it fixes your problem, I will finish my work on that patch and include it in the next official Git for Windows version. |
|
Hi. I came across this issue this evening and found this bug report. So I went testing on a virtual machine to see if your branch fixed the issue. Good news is that it did. I happened to have an old version of git for windows installed (v2.6.3) on my VM before I had even begun so I did a quick test with it. I set Video 1: https://vimeo.com/171162542 Then I installed git for windows 2.9.0. Using the same config settings for git, I tried to clone the same repo. This time I got the error. Video 2: https://vimeo.com/171162543 Finally, I followed your instructions and built a version of git from your I think the bug is fixed. Video 3: https://vimeo.com/171162544 Thank you. |
|
Thanks. In my mail client, I cannot watch the videos, of course (I could have read pasted text, though...) The main issue I have with my patch is that it violates the DRY principle. Rather than copy the |
|
Hi guys, can we expect this issue to be fixed in 2.9.1? Thank you for your work! |
|
Hi guys, maybe this is related to this issue somehow: Since this is the second time I am reporting anything on github please have mercy with my brief description. Thank you for your work and efforts with git for Windows. Kind regards, |
|
Oh well. I used the lousy work-around. |
|
fatal: unable to get credential storage lock: File exists |
|
This will be fixed in the next Git for Windows version. If you need it earlier, you may want to build an installer yourself. (Whenever time allows, which is not often, I am working towards a setup where intermediate installers will be built automatically, we are just not there yet, and please do not expect this to happen anytime soon.) |
As of 1a9d15d (tempfile: a new module for handling temporary files, 2015-08-10), the temporary files which are used by the lock file machinery adjust the permissions, and to do that, the config is read, which in turn requires the config to be read. This means that the runtime prefix needs to be resolved properly, but we did not set that correctly in credential-store. The symptom of this bug: when running printf '%s\n%s\n%s\n%s\n' \ 'protocol=https' 'host=gitblub.com' \ 'username=hello' 'password=world' | git credential-store store an assertion is thrown: Assertion failed! Program: ...\libexec\git-core\git-credential-store.exe File: exec_cmd.c, Line 23 Expression: argv0_path This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. This fixes #766 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
As of 1a9d15d (tempfile: a new module for handling temporary files, 2015-08-10), the temporary files which are used by the lock file machinery adjust the permissions, and to do that, the config is read, which in turn requires the config to be read. This means that the runtime prefix needs to be resolved properly, but we did not set that correctly in credential-store. The symptom of this bug: when running printf '%s\n%s\n%s\n%s\n' \ 'protocol=https' 'host=gitblub.com' \ 'username=hello' 'password=world' | git credential-store store an assertion is thrown: Assertion failed! Program: ...\libexec\git-core\git-credential-store.exe File: exec_cmd.c, Line 23 Expression: argv0_path This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. This fixes #766 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
As of 1a9d15d (tempfile: a new module for handling temporary files, 2015-08-10), the temporary files which are used by the lock file machinery adjust the permissions, and to do that, the config is read, which in turn requires the config to be read. This means that the runtime prefix needs to be resolved properly, but we did not set that correctly in credential-store. The symptom of this bug: when running printf '%s\n%s\n%s\n%s\n' \ 'protocol=https' 'host=gitblub.com' \ 'username=hello' 'password=world' | git credential-store store an assertion is thrown: Assertion failed! Program: ...\libexec\git-core\git-credential-store.exe File: exec_cmd.c, Line 23 Expression: argv0_path This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. This fixes #766 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
As of 1a9d15d (tempfile: a new module for handling temporary files, 2015-08-10), the temporary files which are used by the lock file machinery adjust the permissions, and to do that, the config is read, which in turn requires the config to be read. This means that the runtime prefix needs to be resolved properly, but we did not set that correctly in credential-store. The symptom of this bug: when running printf '%s\n%s\n%s\n%s\n' \ 'protocol=https' 'host=gitblub.com' \ 'username=hello' 'password=world' | git credential-store store an assertion is thrown: Assertion failed! Program: ...\libexec\git-core\git-credential-store.exe File: exec_cmd.c, Line 23 Expression: argv0_path This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. This fixes #766 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
As of 1a9d15d (tempfile: a new module for handling temporary files, 2015-08-10), the temporary files which are used by the lock file machinery adjust the permissions, and to do that, the config is read, which in turn requires the config to be read. This means that the runtime prefix needs to be resolved properly, but we did not set that correctly in credential-store. The symptom of this bug: when running printf '%s\n%s\n%s\n%s\n' \ 'protocol=https' 'host=gitblub.com' \ 'username=hello' 'password=world' | git credential-store store an assertion is thrown: Assertion failed! Program: ...\libexec\git-core\git-credential-store.exe File: exec_cmd.c, Line 23 Expression: argv0_path This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. This fixes #766 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
As of 1a9d15d (tempfile: a new module for handling temporary files, 2015-08-10), the temporary files which are used by the lock file machinery adjust the permissions, and to do that, the config is read, which in turn requires the config to be read. This means that the runtime prefix needs to be resolved properly, but we did not set that correctly in credential-store. The symptom of this bug: when running printf '%s\n%s\n%s\n%s\n' \ 'protocol=https' 'host=gitblub.com' \ 'username=hello' 'password=world' | git credential-store store an assertion is thrown: Assertion failed! Program: ...\libexec\git-core\git-credential-store.exe File: exec_cmd.c, Line 23 Expression: argv0_path This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. This fixes #766 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
As of 1a9d15d (tempfile: a new module for handling temporary files, 2015-08-10), the temporary files which are used by the lock file machinery adjust the permissions, and to do that, the config is read, which in turn requires the config to be read. This means that the runtime prefix needs to be resolved properly, but we did not set that correctly in credential-store. The symptom of this bug: when running printf '%s\n%s\n%s\n%s\n' \ 'protocol=https' 'host=gitblub.com' \ 'username=hello' 'password=world' | git credential-store store an assertion is thrown: Assertion failed! Program: ...\libexec\git-core\git-credential-store.exe File: exec_cmd.c, Line 23 Expression: argv0_path This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. This fixes #766 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
As of 1a9d15d (tempfile: a new module for handling temporary files, 2015-08-10), the temporary files which are used by the lock file machinery adjust the permissions, and to do that, the config is read, which in turn requires the config to be read. This means that the runtime prefix needs to be resolved properly, but we did not set that correctly in credential-store. The symptom of this bug: when running printf '%s\n%s\n%s\n%s\n' \ 'protocol=https' 'host=gitblub.com' \ 'username=hello' 'password=world' | git credential-store store an assertion is thrown: Assertion failed! Program: ...\libexec\git-core\git-credential-store.exe File: exec_cmd.c, Line 23 Expression: argv0_path This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. This fixes #766 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
As of 1a9d15d (tempfile: a new module for handling temporary files, 2015-08-10), the temporary files which are used by the lock file machinery adjust the permissions, and to do that, the config is read, which in turn requires the config to be read. This means that the runtime prefix needs to be resolved properly, but we did not set that correctly in credential-store. The symptom of this bug: when running printf '%s\n%s\n%s\n%s\n' \ 'protocol=https' 'host=gitblub.com' \ 'username=hello' 'password=world' | git credential-store store an assertion is thrown: Assertion failed! Program: ...\libexec\git-core\git-credential-store.exe File: exec_cmd.c, Line 23 Expression: argv0_path This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. This fixes #766 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
As of 1a9d15d (tempfile: a new module for handling temporary files, 2015-08-10), the temporary files which are used by the lock file machinery adjust the permissions, and to do that, the config is read, which in turn requires the config to be read. This means that the runtime prefix needs to be resolved properly, but we did not set that correctly in credential-store. The symptom of this bug: when running printf '%s\n%s\n%s\n%s\n' \ 'protocol=https' 'host=gitblub.com' \ 'username=hello' 'password=world' | git credential-store store an assertion is thrown: Assertion failed! Program: ...\libexec\git-core\git-credential-store.exe File: exec_cmd.c, Line 23 Expression: argv0_path This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. This fixes #766 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
As of 1a9d15d (tempfile: a new module for handling temporary files, 2015-08-10), the temporary files which are used by the lock file machinery adjust the permissions, and to do that, the config is read, which in turn requires the config to be read. This means that the runtime prefix needs to be resolved properly, but we did not set that correctly in credential-store. The symptom of this bug: when running printf '%s\n%s\n%s\n%s\n' \ 'protocol=https' 'host=gitblub.com' \ 'username=hello' 'password=world' | git credential-store store an assertion is thrown: Assertion failed! Program: ...\libexec\git-core\git-credential-store.exe File: exec_cmd.c, Line 23 Expression: argv0_path This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. This fixes #766 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
As of 1a9d15d (tempfile: a new module for handling temporary files, 2015-08-10), the temporary files which are used by the lock file machinery adjust the permissions, and to do that, the config is read, which in turn requires the config to be read. This means that the runtime prefix needs to be resolved properly, but we did not set that correctly in credential-store. The symptom of this bug: when running printf '%s\n%s\n%s\n%s\n' \ 'protocol=https' 'host=gitblub.com' \ 'username=hello' 'password=world' | git credential-store store an assertion is thrown: Assertion failed! Program: ...\libexec\git-core\git-credential-store.exe File: exec_cmd.c, Line 23 Expression: argv0_path This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. This fixes #766 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
As of 1a9d15d (tempfile: a new module for handling temporary files, 2015-08-10), the temporary files which are used by the lock file machinery adjust the permissions, and to do that, the config is read, which in turn requires the config to be read. This means that the runtime prefix needs to be resolved properly, but we did not set that correctly in credential-store. The symptom of this bug: when running printf '%s\n%s\n%s\n%s\n' \ 'protocol=https' 'host=gitblub.com' \ 'username=hello' 'password=world' | git credential-store store an assertion is thrown: Assertion failed! Program: ...\libexec\git-core\git-credential-store.exe File: exec_cmd.c, Line 23 Expression: argv0_path This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. This fixes #766 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
As of 1a9d15d (tempfile: a new module for handling temporary files, 2015-08-10), the temporary files which are used by the lock file machinery adjust the permissions, and to do that, the config is read, which in turn requires the config to be read. This means that the runtime prefix needs to be resolved properly, but we did not set that correctly in credential-store. The symptom of this bug: when running printf '%s\n%s\n%s\n%s\n' \ 'protocol=https' 'host=gitblub.com' \ 'username=hello' 'password=world' | git credential-store store an assertion is thrown: Assertion failed! Program: ...\libexec\git-core\git-credential-store.exe File: exec_cmd.c, Line 23 Expression: argv0_path This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. This fixes #766 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
As of 1a9d15d (tempfile: a new module for handling temporary files, 2015-08-10), the temporary files which are used by the lock file machinery adjust the permissions, and to do that, the config is read, which in turn requires the config to be read. This means that the runtime prefix needs to be resolved properly, but we did not set that correctly in credential-store. The symptom of this bug: when running printf '%s\n%s\n%s\n%s\n' \ 'protocol=https' 'host=gitblub.com' \ 'username=hello' 'password=world' | git credential-store store an assertion is thrown: Assertion failed! Program: ...\libexec\git-core\git-credential-store.exe File: exec_cmd.c, Line 23 Expression: argv0_path This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. This fixes #766 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
I remove the .git-credentials.lock file and it works |
and others
or closed issue
matching what I'm seeing
Setup
output of
git versionas well.git version 2.8.3.windows.1 64bit
Which version of Windows are you running? 32-bit or 64-bit?
Windows 10 Enterprise 64-bit
What options did you set as part of the installation? Or did you choose the
defaults?
Any other interesting things about your environment that might be related
to the issue you're seeing?
Nothing
Details
Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other
CMD
What commands did you run to trigger this issue? If you can provide a
Minimal, Complete, and Verifiable example
this will help us understand the issue.
All below:
What did you expect to occur after running these commands?
Do not issue an error message
What actually happened instead?
File ‘ .git-credentials.lock’ not exist:
File ‘ .git-credentials.lock’ exist:
File '.git-credentials.lock' can not be removed when the command is finish.
If the problem was occurring with a specific repository, can you provide the
URL to that repository to help us with testing?
Sorry, repository is private company repository.
The text was updated successfully, but these errors were encountered: