When I commit a sizable number of files (200 files) through GitHub for Desktop, it just sits there for a very long time (>10 minutes). It does eventually complete.
Scrolling through the debug log doesn't seem to show anything out of place.
This seems to be a recent development, as the previous Github for Windows did not seem to have this issue.
I'm currently on version The Last Free Monad (3.0.5.2) a0622a5, and my git version is 1.9.5.github.0
Any ideas?
Upgrading to the latest version of Git resolved the issue.
The issue with GitHub Desktop is that it includes its own version of git for windows, and you cannot update/upgrade it. I tried before and it didn't work.
But it is also true that since Nov 2015, GitHub Desktop finally went from an old 1.9.5 version to a 2.5+ version, which, as noted by the OP, improves the situation.
Note that you can have both GitHub Desktop and git for Windows (with different versions).
Related
Is there any way I can clone a huge Git repository (16+ GB) using the Git integration of latest Eclipse Neon?
I'm cloning by HTTP connection.
First, I ran into timeouts, but then increased the Remote connection timeout to 1800 seconds in Eclipse config.
Then the cloning almost completed, but at the very end it always fails telling me Premature EOF.
I have increased the http.postBuffer to 524288000 also (as many users suggested on StackOverflow), but this was not much of a help.
I also tried cloning the master branch only, but again, I was stuck with the same error message.
Is EGit not capable of handling such a big repo over HTTP?
The only Git-related way to clone such a huge Git repo would be through the recent (February 2017) GVFS (Git Virtual File System).
As tweeted, for a 270GB repo:
“The Windows codebase has over 3.5M files. With GVFS (Git Virtual File System), cloning now takes a few minutes instead of 12+ hours.”
See github.com/Microsoft/GVFS.
GVFS is based on Git fork: github.com/Microsoft/git.
And based on a protocol whose specifications are described here.
This is not yet supported by EGit, or even regular Git for now.
Depending on what you want to do with the repo, a shallow clone may be the solution (it won't bring the full git history): https://www.perforce.com/blog/141218/git-beyond-basics-using-shallow-clones
also, for such big repo, consider using git lfs in the future: https://git-lfs.github.com/
finally, I've seen many huge git repos that became so big because had files that wasn't supposed to be saved on git (executable files, binaries, videos, audio, and so on). If by mistake something like that happen, you can remove it from history using filter-branch. Check this SO ans: How to remove/delete a large file from commit history in Git repository? or this github article https://help.github.com/articles/remove-sensitive-data/
EDIT:
Microsoft has been developing GVFS that may be a solution in a near future (i think it's still not ready, but I haven't tested)
Do you really have a code project that's 16GB? That's pretty crazy, man!
I think the least painful way to go about this, is to open your shell and just type git clone http://my-url/project.git. And then try to see if you can make the repository somewhat smaller.
Eventually, I ended up cloning the repository using a SSH connection.
This works fine, even from within Eclipse (using EGit).
I had to create a SSH key in Eclipse properties, since Putty's PPK format is not compatible with Eclipse. Then, I managed to clone the entire repository.
Seems like HTTP is not suited to download a chunk of 16+ GB. :)
Here is the context:
I am using egit within Eclipse
I made a number of commits that I have not pushed to the remote repository
I suddenly notice a bug with my app that wasn't there before
How can I quickly update my working directory with earlier git commits until I find the first commit that introduced the bug? How do I then get back to my latest local commit?
I used hard git resets to do this recently and would have lost my last set of git commits if I hadn't found this answer so there must be another, safer way to achieve the same result.
I am running into a bug in my latest version of the code and want to go back in time until the bug no longer shows up.
That is called git bisect, and is not implemented in Egit.
You should consider using git in command-line, in order to launch a bisect session.
I just figured out the answer to my own question.
It's actually quite simple:
Do git checkout of earlier versions until identifying the last version that does not exhibit the bug and the first one that does
Then do a git switch to the master version to go back to the latest committed version
The checkouts are not intended to make further changes to the code but are quick and useful for updating the working directory without messing with the git directory, which is all what's needed to quickly pin-point the appearance of a new bug in the git tree.
I have been forced to use other apps, and the command line since Github for Windows is not allowing me to commit changes. I would like to understand what's the problem, but I simply get a prompt with this message:
Commit failed
Failed to create new commit
Then, it gives me the option of go to the Git Shell or to cancel. While I am not an expert with the terminal, I am able to make commits when I choose to go to the Git Shell (or to any other application for that matter).
I am using Github 2.0.5 on Windows 7.
After an exchange with the Github for Windows developers, the issue has something to do with Windows inability to work with paths when they're too long. The node_modules folders generated by Node.js is the culprit of this issue in my particular case.
However, the node_modules folders in my repository are gitignored. The fact that even when gitignored they create a problem in Github for Windows means the developers have to address the situation.
I expect a response or a patch from the developers soon. They have been very helpful. In the meantime, I am using SourceTree as my Windows Git GUI.
I am having a lot of issues with integrating XCode 4.2 git and github. For some reason doing control+command+c always gives me an error of:
The operation could not be performed because no valid working copies were found.
I check on Windows->Organizer->Repositories and the repo is there. When I click on the folder that has the name on my project and commit using the repository control, I can do commits, now the issue is that the Push is always grayed out. How do I get around this issue? Tried restarting several times and it didn't help at all
xcode4's version control sucks.
you can try gitx(l) instead (download it here)
Anyway, any GUI git client can't do much on git functions. trying to learn git command on console is a better choice.
There is a series of git basics video tutorials - you can even download the video files themsleves in hi def at http://www.ava.co.uk/git - 9 vids in all about 40 mins - they get quite a few thumbs up. We also invested in Smart git - and its almost very good.
I just opened up a project I last worked on two weeks ago and discovered that my working version is several revisions behind (using Mercurial via Bitbucket). The latest compiled assemblies on my dev machine are 100% up-to-date, but my local and remote code repositories are missing all the new code, which I compiled on my dev machine into the latest assemblies.
Disassembling the latest compile (a month old) using Red Gate's .NET Reflector, I can see all my newest code, but none of that is now anywhere to be found on my dev machine, or in any of my repositories. It's like all my code went back to the future. Is it possible I inadvertently reverted and overrode some code from my remote repository and there is no trail of it?
I must not have committed my latest changes, but surely these should still be in my working copy? I am unaware of any system roll-backs. I run Visual Studio 2010 on my Windows 7 dev box and I am sure this is not Mercurial's fault, but is there some functionality I am not aware of? How is this possible?
Not-committing is always a bad idea, committing is how you say "this is something" not "this is finished".
What is the output of hg summary? Is it possible you've hg updated to a past revision -- if so all the new stuff is still in the repo, just not the working directory. Mercurial never throws away committed changes, and only gets rid of uncommitted changes if you use an option like --clean on update. If you did hg revert you'll have .orig backup files unless you did a --no-backup.
In brief, Mercurial won't throw away changes unless you work very hard at it, so either they're still there or it was something external.