I am using the newest GitHub for windows, and this occasionally happen
always suggesting I debug the repo in shell.
I am looking to learn how to do this debug
Is there any source that explains all (or even most) common problems that would cause this?
The repo seems ok when used from command line.
The specific case that is driving me crazy now is a Heroku project I'm trying to work on with a friend who uses Mac. Not sure if that is related, and I want to learn how to debug the general case, but any tips here would be useful as well
Running GitHub with administrator rights resolved the problem as well :)
You can find the "GitHub for Windows" log in
# WinXp:
C:\Documents and Settings\LoginName\Local Settings\Application Data\GitHub
# Or Win7:
C:\Users\LoginName\Local Settings\Application Data\GitHub
I have seen this message:
on authentication problem (I used it in a corporate environment)
when Windows keep an handle on some resources which should be updated by the git pull.
I usually keep a bash opened (launched from the "GitHub from Windows" GUI) in order to repeat the failed GUI operation as a git command.
Related
Question:
Why does git-bash hang when cloning a non-public repo when installed with defaults?
Context:
I ran into this issue when trying to clone a private GitHub repo on my co-workers Windows 10 machine.
Steps to reproduce:
Installed the newest version of git bash for Windows (for at the time of writing this post for me was 2.32.0.windows.1). Choosing all of the defaults.
Run git clone [http-link-to-private-repo]
Expected:
A popup to enter username and password information.
My Hack Solution:
When installing 2.32.0. for windows check the "Enable experimental support for pseudo consoles.".
This allows the bash console to present you an option to authenticate via a web browser or a personal access token.
Unrelated Note:
I originally was looking to post this on the Github Issues page for Git but they don't have one so here I am. Not sure if this is the appropriate place to post this but I wanted it somewhere so another person doesn't run into the same trouble.
Many thanks this was the solution after everything else failed including setting up a new installation, a new access token, and trying to find faulty config files.
After updating my personal access token this behavior also occurred with git 2.28.0.
So i did an update to the newest git version and afterwards the above mentioned steps.
(Sorry, i can not make any comments directly.)
I also ran into this problem setting up my dev environment for a new work laptop... Thankfully I had an older Windows GitBash installer (2.31.1) so I ended up downgrading to the older version. Worked like a charm, for me but understand it may not be an option for everyone.
I cloned a VSTS (NOT GitHub) repository with bash on windows using URL like https://myproj.visualstudio.com/repo and now I'd like to be able to use in-built VS2017 git window for my work, however when I do say Pull I get a window asking for my username/password and after I provide them I get this error:
Git failed with a fatal error.
could not read Username for 'https://myproj.visualstudio.com': terminal prompts disabled
which doesn't make any sense to me, I'm still able to do everything from git bash, I was also able to use VS2017 in-built window until today (we had some accounts migration which I'm not aware of the details), I tried relogging everywhere (at least what I'm aware of) and reinstalling git/visual studio, but still no success. All the suggestions I was able to find are either related to GitHub or suggest me to use ssh, which I don't want to, because my colleagues still have it working quite fine with https as before
A workaround for me was to download and install TortoiseGit and then get a repository cloned through its credential manager. Afterwards, I connected to the repository within Visual Studio 2017 as a local repository.
In this approach we have to use TortoiseGit for all repo operations.
Better to try these instructions, which completely resolved my issue:
https://www.danielcrabtree.com/blog/176/how-to-fix-fatal-error-with-git-in-visual-studio-2017
Turns out I had to delete contents of this file:
C:\Users\my_user\.ssh\known_hosts
I didn't see it documented anywhere, it was just one of my numerous random attempts to fix things
I would like to use Git for a software project which resides inside an encfs enctrypted drive mounted via Dokan (Windows environment). The Encryption of the files works just fine, unfortunately Git does not seem to like working in this environment. When initializing the Git repository I encounter the error message:
error: could not commit config file w:/djangodance/.git/config
When committing I encounter this - disk is writeable and quota is not exceeded:
fatal: Repository has been updated, but unable to write new_index file. Check that disk is not full or quota is not exceeded...
So far I have learned that Git does not seem to like certain drive-mounting-setups. This article (mounting remote filesystem via sshfs) proposes a workaround option (-oworkaround=rename).
My questions:
Did I locate the source of the problem correctly?
Is there some similar setup for Dokan which works with Git?
Is there a different approach which could satisfy on-the-fly encryption using Windows? I'd rather not use TrueCrypt since it is not as useful in combination with Dropbox.
Thank you for any hint!
Dokany is a fork of Dokan. It is very active by the maintainers and the community. It is now know as the main solution for writing driver and porting FUSE to Windows with the same code.
It also have the fix that you would be interested:
https://github.com/dokan-dev/dokany/pull/39
There was a problem with MoveFileEx. Without the fix this API fails with "permission denied" because the target file is opened and cannot be deleted.
Now the git command works via dokan!
The latest release of Dokan appears to be nearly three years ago. I don't imagine you'll get much support with it, even from the community.
You may want to consider using Bitlocker, a full-drive encryption system. Or possibly Encrypting Filesystem to encrypt your development directory. Both of these options are included in recent versions of Windows, and should be fully supported by Microsoft.
I newly started working on Github via their native Windows Application, it's quite good however it's crashing so often and the horrible thing is that I lose all the recent changes after it's crashing. All the local files will rollback to the last version of the successful commit or sync.
I'm on a 64bit windows 8 machine. Any ideas?
The exact error after crash is Couldn't find a HEAD in this repository
I sent an email to GitHub For Windows support. Their answer was this:
Hi David,
I am sorry for the trouble.
I have been able to reproduce this problem, and have filed a report for our developers to look at. The reason the application is crashing is likely due to merge conflicts between the local and remote repositories.
The easiest way to resolve this would be to go into the repository that is saying 'failed looking for HEAD', closing that pop-up, and clicking Tools -> Open a Shell Here.
From the shell, you can run 'git reset --merge' to undo the merge that caused GitHub for Windows to crash.
From there, run 'git checkout master' to switch from the detached HEAD.
After that, run 'git pull' in the shell to pull down any new changes. It will prompt you to fix any merge conflicts (which is what caused the app to crash).
Once you fix the merge conflicts in the files, you should then be able to sync correctly in GitHub for WIndows.
I have been testing this issue, and after I resolved the conflicts with the initial crash, I no longer had any further trouble with GitHub for Windows. It correctly prompted me to open the shell and resolve merge conflicts rather than crashing.
Let me know if you have any further questions, and hopefully we will have a fix out for this soon.
Best,
Steve
This is the solution I received from Github support. I'll copy & paste the exact text here:
The easiest way to resolve this would be to go into the repository that is saying 'failed looking for HEAD', closing that pop-up, and clicking Tools -> Open a Shell Here. From the shell, you can run 'git reset --merge' to undo the merge that caused GitHub for Windows to crash. After that, run 'git pull' in the shell to pull down any changes. It will prompt you to fix any merge conflicts. Once you fix the merge conflicts in the files, you should then be able to sync correctly in GitHub for WIndows.
I have been testing this issue, and after I resolved the conflicts with the initial crash, I no longer had any further trouble with GitHub for Windows. It correctly prompted me to open the shell and resolve merge conflicts rather than crashing.
I had this problem after I made an unstable change to my .gitconfig user file.
I only detected the issue after I tried using TortoiseGIT and it outlined the error parsting the config file with an unexpected token.
So the fix was to correct the bad .gitconfig file.
Often when I do a checkout of a different branch, or a reset, I will get 'permission denied' errors from windows for one to a dozen files - but the particular files vary from run to run. Here's the output from a test I just did, with GIT_TRACE=1. The trace only added the one line before the error message:
$ git checkout master
trace: built-in: git 'checkout' 'master'
error: git checkout-index: unable to create file dotnet/src/myfile.cs (Permission denied)
D dotnet/src/myfile.cs
Switched to branch "master"
I'm pretty sure this is some race with a virus scanner or other indexing service on my machine. If the race persisted, I could use sysinternals to see what process has the file handle open. However, it happens very quickly, and I'm not aware of a tool that will show me this conflict. Surprisingly, I haven't found anyone describing similar behavior.
How do I make these errors stop, or diagnose the problem further?
I'm specifically looking to end the file access race by identifying whatever process is doing the simultaneous access. So suggestions for a tool that shows which process has a file locked when an edit is denied would be very helpful. I'm aware of 'unlocker' and similar tools which will show me what process holds a file locked for a period of time. This doesn't work for this issue, because the process keeps the file locked for a very short period. So the tool needs to collect the appropriate data without my intervention, as I'm too slow.
It might be the Windows Search Indexer, which tries do index files as they are created. I ran into this issue with svn checkout and had to exclude that directory from indexing before I could successfully checkout a full project.
See my post https://connect.microsoft.com/VisualStudio/feedback/details/676699/cannot-open-linker-output-for-writing-or-cannot-close-file
Not git related!
Sysinternals' process monitor reveals that Windows explorer interferes with newly created files, perhaps due to some plugin or what, but it happens.
Disabling UAC Virtualization seems to have fixed the problem.
See http://code.google.com/p/msysgit/issues/detail?id=320
You can begin with a:
GIT_TRACE=1
But it may not display much more than your original message regarding this file.
The usual cause is some opened editor which wants to reload the files when changed, and that can conflict with git's file manipulations.
That means: the usual strategy is to repeat your git command after having close as many other applications as you can.
I haven't found anyone describing similar behavior
See this thread for instance, ot this one, both on Cygwin.
What version of Git are you using (Git on Cygwin, or MSysGit, in a Cygwin session or a Dos session?)
You could try Filemon from sys internals