I've looked all around for a few days now trying to figure this out because our .gitignore even though it lists /bin/ folder it still keeps freaking commiting the whole folder and its getting annoying.
Now we have a whole bunch of crap in a /bin/ folder in our GitHub repository and I have no idea how to remove it. I've tried looking at other peoples examples but they keep talking about a shell command that I don't have in eclipse (or at least don't know how to access)
The sad news is that if a file has been already committed to GitHub, git will continue to version that file.
This means if I commit the entire bin/ then add it to .gitignore, the files will still persist in GitHub. And, if these files in bin/ change, they will also be pushed in the commit because they are versioned.
Luckily, you can remove files and directories from GitHub completely. You need, though, to get to a command line running git. If you have the GitHub application installed, that probably means you have git.
Open command prompt in Windows or Terminal in Mac OS.
Navigate to the directory (ie. cd ~/Workspace/Project) and run the following:
git rm bin/* -f
git commit --amend
git push -f
This should work. Check out this article on the GitHub that also outlines the process.
Hope this helps you!
Disclaimer: always make sure you do your research before working with git. If you have various branches / other complicated stuff going on, this process might be different
Related
I've recently moved to Github (VS2017's built-in support) from Perforce for some individual projects. There is a feature in Perforce called "make writable" that allowed you to write to a file locally and then only submit it to the server by explicitly checking it out then submitting it.
This was used extensively for any binary files (.exe, etc) that only needed to be pushed very rarely but still needed to be written to.
Unfortunately from my limited experience with Github, it seems that all files are set to writable and are always marked as "changed", even exes. Is there a setting I can make or setup that allows Github to only mark a file as changed explicitly so I can't accidentally push an incomplete, broken, or debug .exe?
Updated answer: So, I forgot, if the file's tracked by Git at any point, then it gets a bit ugly. There are ways around this, but it isn't a single command to do this.
IF you want to do the .gitignore route, you can. But there's an added step (see below for first step). You have to, after each commit you do of the .exe file, run git rm --cached <filename>. This will remove the metadata around the file telling Git to track it. Once you do that, it won't show up anymore in the Changes list in the Visual Studio plugin (if you're on commandline it won't show up in git status). Then to add a file, you do what I mentioned below, which is to do the git add -f <filename>.
If instead, another way to do this, would be to run git update-index --assume-unchanged <filename>. This tells Git to ignore changes to the file. When you want to commit it, first run git update-index --no-assume-unchange <filename> and do your normal git add git commit workflow, then once you've committed it, run again the git update-index --assume-unchanged <filename> bit. It's messy, and honestly, I'd write a custom tool in VS to do this rather than relying on the built-in SCM tool in Visual Studio.
Original answer: Best way to do this (IMO, others will have their own opinion) is to add the files to your .gitignore. Then if/when you really want to commit them, do a git add -f <file> and then commit as normal.
Edit: Note that this is something everyone will have to do to avoid accidentally committing. A way around that is to commit your .gitignore as well so everyone has the same behavior.
After my first attempt at committing a couple of large folders (angular and django), git responded with:
Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.
Previous posts recommend:
removing the index.lock in the .git folder.
I've done this, but the second that i resubmit "git add . " as part of my git push origin master routine, the index.lock file reappears in .git
Is there another solution? And what has happened to warrant this?
I've tried all the suggestions in the commented link
I'm working with this:
git version 2.13.5 (Apple Git-94)
In my case, index.lock wouldn't delete. Instead, I found that one of my django folders lacked a .gitignore, so I created one and included the following files:
include
lib
include
bin
.vscode
You might want to include more or less, depending.. Apparently, I was attempting to push a file that disagreed with git.
In GitHub for Windows, files that have been git rm --cached still appear in the list of changed files. Is there any way to hide them?
You still need to add the files to your .gitignore file.
http://www.gitguys.com/how-to-remove-a-file-from-git-source-control-but-not-delete-it/:
The git rm command will allows you to remote a file from git control.
The –cached option to git remove allows you to leave it on your hard
drive.
Every once in awhile a file gets checked into git that isn’t supposed
to be there. Common examples are configuration files, project files
generated by your IDE with personal settings and even the occasional
object file that someone decided to check in. These files are needed,
so often you can’t delete them entirely and the process of copying
them somewhere else, removing them from git and then replacing is
painful, not to mention prone to error.
By adding the –cached option to the git rm command, you are able to
remote the file file from git control while keeping the file in your
working tree. They command syntax is:
git rm --cached file
Git will no longer track this file even though it is still on your
hard drive.
After running the above command, be sure to add an entry to your .gitignore file so that ‘file’ doesn’t show up in ‘git status’ and that it can’t accidentally be re-added later.
I wanted to unstage files (as my .gitignore was not set up to ignore some of my IDE files) but in hurry did :
git add w3
//got some .settings etc folder and files added, in newly added sub folder w3
//the repo here already had sub folders w1 & w2.
Then issued:
git rm -f w3/*
I'm on windows 8. The files are hard deleted (not in the recycle bin). Any thing I can do with git or any other (free) way?
Edit Add
* Also it was opened in STS(eclipse) but now deleted the pom, settings everything. Anyway to restore from within eclipse?
Un-commited but added files are still in a repository for a while, however it would be quite tricky to restore it especially for a large old repository as usually it has a lot of garbage. So, if you don't mind dig into garbage, start with git fsck and look for dangling blob.
However, seems you cannot restore names of lost files, only content.
If the file was not versioned you can't restore it. See the documentation of git-rm. See here for how to undo adding a file to the staging area.
If the file was versioned you can retrieve it from a past commit. See this answer for more information.
Of course if you back up your drive you might be able to restore it with your back up program. For that you might get help over at SuperUser.
I've got Composer installed and I've used it to download HTMLPurifier locally. Now I'd like to push that download to my OpenShift Git repo. So, in a Git Bash window, I run the following...
git add -A :/
git commit -a -m "Uploading HTML Purifier"
git push origin master
At this point Git reports that the push was successful but when I ls the directory through SSH, it shows that the HTMLPurifier directory is empty. Why is that? How do I get Git to push those files?
Additional Info: I noticed that the HTMLPurifier directory is indeed a Git repo itself and contains a .gitignore file in its root directory. I tried deleting it and re-running the above commands but to no avail...
You should try to avoid pushing downloaded dependencies into a repository. It is recommended to add the vendor directory into the .gitignore file at top level. But what you must do instead is commit and push both composer.json and composer.lock.
Here's why: The vendor directory is managed by Composer. Running Composer will probably do minor things during an update, but may also be doing heavy stuff if the Composer team decides to optimize things.
Also, if you require a branch of a package, and Composer knows the repository of that package, it will default to cloning a Git repo or do a SVN checkout instead of trying to grab a ZIP package of that branch (often there is no way to get such a package for branches, and even tagged versions in a plain Git repository do not have such download ability. Composer knows that Github offers such downloads, and detects Github by looking at the repo URL.)
So you can assume that Composer will put a lot of repository meta data into the vendor file, and if you blindly commit these, things will get ugly. First of all, you are committing way too many files, increasing your repository by an unnecessary amount, which will slow down things. Then, if cloning Git repositories, these will be treated as submodules, and that has another bunch of nastiness I am told. If you are just learning Git, it probably isn't a good idea to start with these. And if you are sufficiently known to the tools (Git and Composer), you probably won't need them either.
There really is only one reason why you'd try to commit a modified version of the vendor directory: If your release process is completely depending on all files being present in your one repository, without any way to run a composer install during the release to make these files appear on the target server.
In such cases, you'd install or update the packages with Composer, and then go through all created directories and delete any .git and .svn (and probably also .hg for Mercurial) folders you encounter. Only then you'd be able to commit the files into your own repository.
But note that this step might be a tedious step to do manually - you probably want to create an update script that does all that work for you. You also might run into issues when updating dependencies because Composer expects files to simply go away when deleted, and not be in the way when being written. I cannot tell you exactly what you'd be experiencing because it depends on how you'd do stuff, but I expect you stumbling upon random puzzling issues.
Bottom line: Avoid committing the dependencies into your own repository if possible.
Try using the -force option, you will also most likely need to delete the .git directory inside the HTMLPurifier directory too.