I created a BitBucket repository of several Eclipse projects, and then used Eclipse with EGit to clone that repository to a new Eclipse workspace to check whether I had put all of the files into BitBucket right.
The projects in the new workspace contained *.class files in their bin directories, and I realized that I had neglected to delete those files from the Eclipse project directories in the original workspace before adding the projects to the repository.
However, the BitBucket web page for my repository doesn't display any bin directories in the various Eclipse project directories, and when I try to remove the *.class files from the repository that I cloned, I get an error message that says, for example, "fatal: pathspec 'EclipseProjects/IndexerUtils/build/uw_solr/CmdLineOption.class' did not match any files".
I assume this means that the class files are not being tracked, but I'm not sure. I don't know Git well enough to figure out how to find out whether they are tracked or not. Their presence does not cause "git status" to say that untracked files were found, but if I try to remove any of them, Git says it doesn't know about them. In the meantime, BitBucket doesn't display any of the class files in its repository, but when I clone its repository, all of the class files are included in the new repository that is created.
Is there a Git command that can tell you whether a specific file is being tracked or not? If the *.class files are being tracked, how do I remove them, since apparently "git rm " doesn't work? If they aren't being tracked, why do they show up when I clone my BitBucket repository? What kinds of basic diagnostic commands does Git have that could help me figure out what state my repository is in?
Thanks,
Mike
do you have a case collision; try setting following and see if you can see and remove file using git rm command.
git config --global core.ignorecase true
Please note this "git rm" removes file from that commit onwards. If you want to remove file thoroughly please consider filter-branch
example: git filter-branch --tree-filter 'rm filename' HEAD
Related
I am new to Sourcetree and source control in general. I am working on an Android project with a few other people and use bitbucket as the repository. I have learned the basics but don't want to track certain files in my local, specifically a lot of the gradle and iml files. But i think Stop tracking will remove those from the repo. Is there a way to just have source tree ignore any changes i make to certain files locally but not delete them from the repo ?
Thank you in advance
You can create a file and name it .gitignore in the root of the project and in that file place every directory to exclude by git like:
my_folder
my_folder2
The above would be excluded from git tracked files.
If you are already tracking files this command will remove them from index:
git rm -r --cached <folder>
I'm trying to ignore obj, bin, debug type files/directories from my Visual studio project. I've followed the advice here:
ignoring any 'bin' directory on a git project
This is not working.
I've pasted the entire git ignore here:
https://github.com/github/gitignore/blob/master/VisualStudio.gitignore
This is not working.
I've tried all sorts of things...
bin/
obj/
*bin/
*obj/
/bin/
/obj/
packages
MyProject/MyProject/obj/
MyProject/MyProject/bin/Debug/
MyProject/MyProject/obj/*
MyProject/MyProject/bin/Debug/*
The directories and their files are still being included when I run a git add. The .gitignore file is added and commited. What am I doing wrong???
EDIT: The files I'm trying to ignore aren't already being tracked. When I run a "git status" there are no pending changes. "nothing to commit, working tree clean". Then I run my VS program which modifies the files in those folders. Then I run another git status and all of the files show up as "modified"...
EDIT2: Does it matter if the files already exist? They are not being tracked but DO exist in the folder structure. When when I run the program they show up again as "modified". Then I have to run a "git checkout ." to remove them all. Then the cycle repeats...
If your file was already been tracked and committed before adding in .gitignore, it won't ignore it. You would require to remove it from index to stop tracking
For file
git rm --cached <file need to remove>
For Folders
git rm -r --cached <folder>
So that would be an issue in your case since Jenkins is still able to see the file in the repo
Hi look at the edit part ,
If you already have any folders in your git index which you no longer wish to track then you need to remove them explicitly. Git won't stop tracking paths that are already being tracked just because they now match a new .gitignore pattern. Execute a folder remove (rm) from index only (--cached) recursivelly (-r).
git rm -r --cached yourfolder
Based on your "Edit 2" above, it sounds like you don't think these have been previously committed, but in reality, they have been. If it shows up as "modified", the git is recognizing the file has changed from the last version it has checked in. If the file was not already committed previously then it would show up as Untracked.
When you are running git checkout on those files, you are telling git to revert those files back to the last version that was checked into git.
I've got an ARM project in Eclipse...Actually, I'm using the STM Workbench packaging of Base-CDT-Eclipse.
I'm working with a few other guys and we're using a git server to push and pull from.
However, everyone has a little bit different setup as far as where their toolchains are, OS's, etc.
This is causing trouble, because we're git dummies, and when we push changes after working locally, we do
git add .
git commit -m "some message"
git push origin master
And when we pull changes, we just do
git pull origin master
And pray that there no one else did anything in the meantime, because we're afraid of merging differences, but that's a different story.
Anyway, this whole project has a few sub directories that include things like datasheets, Word documents, and what-not...but, it also includes the metadata for the Eclipse project. So, the last person to commit also pushes their unique settings for things like tool-chain path, preferred builder, etc. This breaks the other guys' setup and after each pull, everyone else has to manually update their project settings to fix this.
So, what files are special to Eclipse for project settings and how can I tell git to ignore these files if they already exist? They need to be available for, say, a git clone but they need to be ignored for subsequent git push's and git pull's.
If you need the setting file and not rename it and it's ok forsetting file need not to do version control, so there is a way by .gitignore with below steps:
Create a .gitignore file. touch .gitignore
Edit and save the .gitignore file
.gitignore
filename
Remove the caches from version control. git rm --cached filename
Commit and push
You can ignore those files changes locally with:
git update-index --skip-worktree -- .project
git update-index --skip-worktree -- .classpath
See: "Difference Between 'assume-unchanged' and 'skip-worktree'", it should better resist to git pull.
Another option would be to a content filter driver which generates (automatically on git checkout) a .classpath if it does not yet exist.
That allows you to version a .classpath.tpl template, and you can keep your actual .classpath completely private (and in your .gitignore)
See this answer for more.
There are some files/directories in the remote git repository for my project that I don't want in my local repository. They are useful to other project members, but not me. And I can't just identify them in the root .gitignore file because when that file becomes part of the remote repository it becomes the rule for everybody else so they change it back. We don't want to get into a .gitignore war.
Is there a straightforward way for me alone to selectively chose the files/directories that I do or don't want to exchange between the remote repository and my local repository when I do a 'git pull'? To be clear, I'd like to make my selections once and have them take effect every time I do a 'git pull' (or equivalent) and not force them on anyone else.
You can add .gitignore to your .gitignore file.
You then git rm .gitignore and it is no longer tracked.
Then just remove the other files you don't want tracked.
I am new to GitHub and finding it incredibly hard to learn. I am following the instructions here to create new repositories from an existing directory containing the project and typing git init ... etc.
However I created a repository in the wrong place and then deleted it by going into Settings at github.com. Then, when I tried to re-push the files the way I wanted it, one of the subfolders is now black (the one I had just deleted the repository for) and now not clickable - i.e. does not appear to be there. See statistics_project1 in screenshot below.
It's very hard to troubleshoot a problem like this. There is no error message or explanatory text when you hover over the black sub-folder.
This post seems similar but I don't know. The solution looks complicated.
Cannot remove submodule from Git repo
Could someone please tell me what a black 'unclickable' folder means in a github repository?
Cannot remove submodule from Git repo [duplicate] had give the answers and steps to do if you have git installed.
"Via the page Git Submodule Tutorial:
To remove a submodule you need to:
Delete the relevant section from the .gitmodules file.
Stage the .gitmodules changes git add .gitmodules
Delete the relevant section from .git/config.
Run git rm --cached path_to_submodule (no trailing slash).
Run rm -rf .git/modules/path_to_submodule
Commit git commit -m "Removed submodule "
Delete the now untracked submodule files :rm -rf path_to_submodule"
copy from remove a submodule
In fact the solution was a lot simpler. The 'blackened' folder is in fact the old repo that was not properly removed locally. As recommended by the author of the minimal tutorial I mentioned above, I simply removed the .git subdirectory which contains all git info and then re-pushed the repository to github.com and now everything is back to normal.