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.
Related
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'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.
I thought this would be a no pbrainer, but for some reason can't find anything on the issue - is there a way to push only specific files from egit? Our repository contains a lrage number of files which are mainly of no interest to me, and every time I try to push I get many DIRTY_TREE errors in files I don't care about. Right-clicking on a file and then attempting push, just tryes to push the entire repository
I'm using Eclipse Juno from mac, and BitBucket repository
Thanks!
Git push deals with commit objects, not with files. If you want to push specific files, you have to make a commit that contains only those files. In your case, you might want to look at the git update-index --assume-unchanged <files> command, or at the .git/info/exclude file, which is like .gitignore except it's for your local repository only (doesn't get shared with the upstream repo).
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
I have a git repo at the workspace level. i.e. multiple closely related Eclipse projects in one repo.
If I add .metadata to .gitignore then each time I create new branch and checkout I loose my .metadata file and therefore import all the projects manually. This is unpleasant.
Is it safe to store the .metadata file under version control? This is a multi-developer project and JDK versions and perhaps even OSs (in future) may vary. (We're all on Ubuntu at present.)
Are there any other IDE files which shouldn't be comitted?
Thanks,
Chris.
The problem is that the file and/or directory was already tracked by git before you added it to .gitignore:
for a file, it will continue to be tracked, no matter what;
for a directory, files present in this directory at the time you added it to .gitignore will also be tracked.
This means, among others, that if you have a file f which is untracked in branch b1 but you checkout branch b2 in which this file is tracked, git will remorselessly overwrite f.
As mentioned in the previous question, the solution to make git completely ignore such files after "the harm is done" consists of issuing git rm -r --cached and only then adding them to .gitignore. But this needs to be done branch by branch, which means you will still have the problem in the meantime.
Given your situation, you have two choices:
if you can afford to restart "from scratch", do so and put .metadata immediately into .gitignore -- and commit that first, before even committing the rest;
if you cannot afford that, you have no choice but a git filter-branch.
As to other files to ignore with other IDEs, I can only tell for IDEA: .idea and *.iml. No idea for others...