I have a rather large (1300 files, 1.6GB) Netbeans Java project that I've been trying to set up on GitHub using the inbuilt GitHub facilities of Netbeans. After Commit I attempt to do a Push. It quickly gets to 22% and just hangs there saying it's writing objects. What are the possible causes of this?
Also, is the writing it's referring to on the GitHub server or my machine?
Obviously, am a GitHub newbie.
I deleted the Repository and started over and it worked.
Full disclosure: On my first attempt I had included several (unnecessary) files over 100MB each and the Push failed with an appropriate message. So, I "deleted" them my unselecting the check boxes in the NB dialog and did a Commit, then attempted a Push. Apparently, this created an unreported error that caused the hang.
Related
Currently I'm facing an issue while installing Kura using Eclipse Installer.
Attached the screenshot and log for further reference.
I hope the issue is unable to pull from git repo.
Could somebody help me out and let me know in case of any further details required.
UPDATED as on 03-09-2017
Now the issue is different attached the screenshot for your reference and when I click back the git repo is not found .
I trying to setup more than a month but still couldn't it what is the other way to explore Kura.
From this eclipse bug, this is more likely related to a network issue.
It seems the session has been dropped in making a channel connection.
|And most important: How can we avoid this?
There must be many reasons for unexpected session drops caused by
external factors, so I suggest to re-try making sessions or channels
at such a case.
If that persists, try and use https url:
git config --global url."https://".insteadOf git#
The error message seen looks like JGit issue 455005:
java.io.IOException: Could not delete file C:\path\to\repo\.git\objects\pack\pack-5cb....pack
That's a common problem on Windows systems. As soon as you open a repository and do operations which access the packfiles (nearly all git operations do that: staging view, history ...) JGit caches data from the packfiles and keeps handles to packfiles open. But as long as handles are open you cannot delete the file under windows.
On Unix systems you don't have this problem because you can unlink files on which you have open file handles. The root cause for your problem is that we delete the repo only halfways. Aftwards we have a corrupted nearly empty gitdir and that reflog doesn't work on that is only the smallest of all problems.
check if the issue persists after a reboot (to make sure there is no other process preempts the file).
If not, try deleting fully (with Eclipse closed), and try again to clone it.
See also bug 336800:
You are creating a new Git object that has a repository associated with it.
This repository is automatically opened and thus has to be closed so that file resources are released.
I have a git repository in which I work in collaboration with some people but I cannot sync anymore. I am using the GitHub Windows client application on Windows 7:
Last time I synced, the operation succeeded and I ended up with a perfect copy of the latest code.
Next, I made some simple changes to a few files, but did not commit anything yet.
In the meantime, someone else made changes to some other files.
In order to see the changes of the repository, I'm trying to sync again.
GitHub client reports "Sync failed".
Now I am wondering if this is normal behavior or if there is something wrong with my repository ? Shouldn't I be able to sync the repository and get latest files even though I am making some changes that are still not committed ?
Thanks.
When you got this kind of error just try to open a git shell and type git status into your working directory. You will have some infos that could help you like which files are in conflict.
It must be one of the other collaborators that updated and pushed a file you just updated. If so, you will have to choose which version you want to keep in your local files.
I am trying to set up GitHub Desktop (3.3.1.0) on Windows 10 with an existing Eclipse Java project, created in Eclipse (Mars.2 Release (4.5.2)). I am able to initialize and successfully make an initial commit and push. However, after every file save operation in Eclipse, a new commit message appears in GitHub Desktop with the following description, {"types":"C","runs":0}.
Can anyone explain this behavior? I assume that it is the Eclipse editor that is automatically committing my changes because I tried saving changes in Atom and no such commit message appeared.
I also attempted to uninstall and disable EGit using the instructions found here, but this seemed to have no effect.
Earlier I began work on a project that was not connected to SVN. So, first things first, I connected it up using Subversive and "Attach projects". Subversive kept giving me authentication errors, but the correct versioning appeared on the files, so I assumed it had attached.
I then did my work in the project, writing a blog post.
I then wanted to commit it back. The authentication errors persisted so I could not commit the work. I noticed that the connection to SVN was actually to a parent path of the module I wanted to commit to - this would cause the authentication errors. The path I was connected to was:
http://mysvnserver.com/svn/
It should have been:
http://mysvnserver.com/svn/blog-projects
The module was chosen on the basis of the existing SVN data I think. There are multiple projects involved, so maybe one of the modules was different and it chose the nearest common parent?
So I discarded the SVN location and went back to re-attach the projects to the correct module.
... but my projects were gone.
No sign of them on the filesystem.
No way of restoring from local history.
Was this supposed to happen? I'd assume not. I've just found this which seems to be the same problem: https://bugs.eclipse.org/bugs/show_bug.cgi?id=376798
Is there any way of restoring this so I haven't just lost a load of work?
I'm trying to checkout a project from an SVN repo (#assembla), and I'm getting wierd errors that all state the connection has been reset by the remote host...
The wierd thing is that I only get these errors when trying to checkout into my USB drive - when trying to checkout into my HD I'm not getting any errors...
I've tried checking out via Tortoise SVN, Eclipse's Subclibse and Subversive and all have the same problem.
Some things I've noticed:
The error always occurs when it's trying to check out the main images folder, though not always on the same file in that folder.
I was able to check out smaller folders (I was even able to check out the problematic folder on it's own).
It seems the error occurs when about 1MB of data has been transferred, so that might explain the previous bullet.
I also noticed that checking out into my HD was a lot faster, so perhaps assembla is terminating the transactions because they're taking too long?