I'm using EGIT to manage my GIT repository, which seems to work well so far. However, when I switch from one branch to another the files are correctly switched, however empty directories and packages that exist in one branch but not the other are left over.
I understand that GIT is based on the actual files and not the directories, however this is not ideal as my one branch was a large refactoring and therefore contains many packages that the master branch does not have.
From my research there appears to be a GIT command git clean -d that should cleanup the directories. Does EGIT support this? Or is there a way to execute this command when switching the branch with EGIT?
That looks like bug 345585: "EGit does not prune empty folders when switching branches".
It is still opened, so for now, the git clean -d is your best option (but outside of Eclipse, in a shell session).
Update June 2013, for Egit 3.0 Kepler:
A clean action has been added to the repositories view now.
Related
The case:
Locally, I have a commit where I have deleted a file. Remotely, someone else have changed this file.
Now, when I merge, I find that git has the put the changed file in my working tree. This is probably the way git works, and in git command line, I'd be able to use git mergetool to choose between the deleted or changed file.
In eGit, however, how would I make this choice?
We ended up with a quite unusable work-around where we first addded the file to the index and then deleted it in working tree and then saved this change (deletion) to the index.
Technical info:
The version of eGit (feature) we're using is 4.9.2.201712150930-r.
The version of git we're using is 2.16.1
Background:
My team have recently moved to using Git as our revision control system. There's a general wish from team members to use an integrated solution and since we're working with Eclipse, eGit seemed to be the way to go.
I would suggest that all your team members follow this process:
Commit your changes to your local repository.
Pull with rebase to merge with the remote origin branch.
Resolve the conflicts, if any. In your case, if you deleted the file before the other team member modified it, then that person would have noticed that the file has been deleted.
Push the commit upstream.
This process has worked for us. Hope this helps.
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.
This is the first time I do this.
I imported a git project in eclipse.
Then I used the shell to create another branch and checkout to the new branch.
Is refreshing the imported project in Eclipse enough to tell Eclipse that we are working on the new created branch?
thanks
Right-click your project and select Team → Branch to create new branches or to switch between existing branches. You can also switch branches in the History view.
Actually, I don't think you even need to refresh the project. That is, assuming you have 'eGit' installed and your projects are already configure as git projects (they should be, because in most cases, egit does that automatically).
Whenever you run git commands on the shell (outside eclipse) egit will automatically refresh projects for you and update their status when you switch back to Eclipse.
If you are not using egit then yes, you have to refresh the projects manually, but that is all you'd have to do since running the 'git checkout my-branch' command in the shell already changed the files on disk to be those from 'my-branch'.
Actually when you are working with eclipse, eGit is a very cool tool integrated inside eclipse, which lets you do all git stuff, like
git checkout to a new branch
git create new branch
git stash
even view your unstaged changes(select files and avoid complexities caused by git add .)
and finally commit.
Read here to know more. Eclipse Egit user guide
So you get to do all version repository stuff at one place as you code.
So to answer your question, yes as you checkout a new branch even in a shell/command prompt your changes will be reflected in eclipse.
I'm running this on Windows Server 2003, and using the Cygwin version of the Git command line tools.
I have a Subversion repository containing a set of Eclipse projects, and am testing migration of this repository into Git. From the command line I've used git svn to create the git repository, and git clone to clone the new repository locally. In Eclipse I use the import wizard "Import->Projects from Git->Existing local repository" to import the projects from the local clone.
Once the projects have been imported, EGit shows an apparently random selection of source files as having unstaged changes. Comparing the files reveals no differences with the version in Git, and replacing the file with the HEAD revision has no effect.
Eventually after much head-scratching I tracked down the problem.
In the original Subversion repository, a number of source files had been checked in with the Subversion svn:executable property set. This property is honoured by git svn, and when the file is ultimately presented in the Git working directory it has the execute permission property set. Even though this is how the file is configured in Git, EGit looks like it isn't seeing the permission set in the repository and is treating it a difference between the repository copy and the working copy... hence it appears in the list of unstaged changes.
I fixed the issue simply using chmod -x on the affected files from the Cygwin bash shell, and committed the changes. I understand that setting the Git property core.filemode=false should also resolve the issue, although I've yet to try this.
I'm running Eclipse Kepler Service Release 1 with egit for versioning. I've been using eclipse and egit for just a few months and am not up on all of it's intricacies yet. I've found some related questions here for git, but I don't really understand how to use egit to accomplish what the answers propose.
The immediate problem I have is that no files are visible in the project tree except for the libraries and WEB-INF under war. The files show up in the unstaged changes area of the Git staging window marked with an x as deleted. This is a jsp project running google app engine if it matters.
What got me to this point was attempting to checkout the master branch. I got an error saying the branch could not find 2 files and afterwards my working files in the current branch disappeared. The Git repositories view shows my current branch is the same as the one I had been working on, so these files should normally be visible.
Since I never chose to delete these files I have no idea what stage egit thinks it's in. I don't have a backup and my other branches haven't had recent changes merged in.
You can always see the state of Git as a text decoration next to each repository node in the repositories view of the Git perspective. Normally that should only show the branch name, but it might also be something like "Interactive rebase", if Git stops for user input in the middle of an operation.
If that is not showing the branch name you want, then just the context menu Switch->[branchname] should bring you back to the wanted branch.
If everything else fails, you can always throw away all local changes and have your local working directory reset to the state of any commit (or branch) by using context menu->Reset->Hard and select the commit (or branch) to which you want to reset. Be aware that this wipes out any uncommitted local changes.
In case of more questions, you should read the very detailed EGit user guide.