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.
Related
I have a problem with Gitlens extension. Firstly, Gitlens or Git History extension is working fine on any other project except the this Laravel project. My problem is, can`t see the file history or line history in this project.
On the other hand, there is no problem in the git log (Git History Extension) as seen in screenshot;
But I can't compare any files with their any version (every commit seems like in the ss). I have no idea what the problem is about.
Lastly, I don't think the problem is about extension settings because other projects do not have this problem. Is there a any chance to fix this issue without resetting git history?
I am answering after 3 months, maybe it works for someone. As I mentioned in the title, surely there is no problem about extension settings for this specific project. The problem is just about git files. Maybe, I damaged some git files while moving the project on my desktop :)
So, there is no chance to fix this issue without resetting git history or starting fresh with git, if you`re having the same problem.
Do not play with git files, it`s no joke!
I've got a similar issue. My problem is in using symbolic links for folders.
I have this folder symlink for my repos.
C:\>dir
Directory of C:\
27.09.2018 21:07 <JUNCTION> repos [C:\Users\Qwerty\repos]
(GitLens v11)
The top editor is opened via C:\repos
The bottom editor via C:\Users\Qwerty\repos
You can see that some git features still work (yellow), but others don't.
However, this is very strange, because in my other repos, I have never observed such issues.
Also notice below that it is still possible to invoke the same action via a git lens popup and then it is possible to use the Prev Next Revision buttons.
Anyway, after more testing, I actually observe the same thing in my other repos. I assume that something must have changed between versions as I only observe these issues for last maybe 2-3 months. I even submitted a ticket that GitLens stopped working in v12.0.0 and later versions https://github.com/gitkraken/vscode-gitlens/issues/1979
The buttons completely disappeared and even the commit information
v11
v12
And Now actually, after having reopened my repo via original path and after updating GitLens back to v12.0.6 I see that it is working properly!
Bottom editor is opened via C:\repos symlink.
I have XCode Server set up with XCode 6.4 and OSX Server 4.1.5. I had integrations running fine until I transferred my git repository to another bitbucket account. No big deal right? Wrong for me :(. After I transferred my repository, I changed my git remote, I changed the repository location in Preferences in Xcode on my dev computer as well as on my server. Regular git functions are working fine from the command line and from within XCode. Nothing seems wrong until I try to run an integration and then it gives me the following build service error:
Could not check out sources because the source control information is in an invalid format.
I tried deleting my bot and creating another one. I tried cloning my project straight from the new location into another folder in case something had gotten out of sync. I git reset hard to the remote branch just in case even though there was nothing different. I tried cleaning and restarting everything multiple times. I reset XCode Server too (sudo xcrun xcscontrol --reset) and am still getting the error making me think I really did somehow mess up my git repository as far as XCode is concerned, but I have no ideas about what XCode doesn't like about my source control information. Does anyone have any ideas for what I can do or try? I've been tearing my hair out for hours.
I'm running XCode 6.1 and working with a git repo. XCode's source control is turned on, as well as the options Refresh local status automatically and Refresh server status automatically and Add or remove files automatically.
Every 10 seconds or so, xcode shows every file's status as changing to unknown (a question mark). After a bit, they mostly all refresh and show the correct status. This keeps happening over and over.
Why is this happening and how can I stop it?
They look like so:
Question Marks
Normal
Finally I have found the cause of this problem, and thus the solution.
My git repo was checked out on my local machine inside of another git repo by accident. Doing this cause massive confusion to XCode, apparently. Doing a fresh checkout in a different folder fixed the problem.
To resolve this you need to do the following:
Go to Source Control -> Refresh Status.
It should solve your problem.
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.
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