I recently created a project on Eclipse. I set up a git repository on the project. Pushed the code to a new repository on GitLab.
I checked out (Import->Project from Git) the project to another laptop, made updates, committed it as another author and pushed it back to repository (2nd commit /revision). I only removed the target runtimes from the project as the changes.
I went to my 1st laptop and wanted to try update / pull my code. I right-clicked on the repository from the Git Repository view -> Remote -> Fetch. I entered the path to the repository and etc and fetched the repository. But, my project still has the old code having the target runtime. I know I only 'fetched' the repository, not 'pulled' maybe.
So I was confused, the code was not updated. If I am not mistaken, I right-clicked the repository again, clicked on 'Check Out'. This was the result :
After 'Checkin Out', the target runtimes on my project were removed, updated like from the 2nd commit. But there are now 2 branches and 2 refs. I don't what state my local repository is in now. And/but the local master branch was still in 'initial commit', isn't it confusing?.. My code has been updated..
I only read a bit of the git manual online, and I haven't yet be able to wrap my head around concepts like refs.
I could just delete the project and Import->Project from Git, right?
But if I can I would like to know what happened to my project (local repository) and how to fix this?
Thx
I'm not familiar with egit and its menus. But I try to answer your question with git commands which you can run in the console. And I think you can figure out which egit menu items are corresponding to these commands.
You wanted to pull and update the local master in the first laptop repository. You needed git checkout master first, which could be skipped if you were already on master and then git pull origin master. However you did git fetch origin master instead, which just updated origin/master with the new commit. It would have been okay to use git fetch origin master if git merge FETCH_HEAD or git merge origin/master followed imediately, because in many cases pull = fetch + merge, but you didn't.
I guess you then did git checkout origin/master. Checking out origin/master leads to detached HEAD state. To make it easier, you could just consider the detached HEAD as a nameless branch. When you make new commits, this namelss branch will grow. But you can't see these commits on other branches unless you apply these commits to them. Git has some commands to apply commits, including git merge, git rebase, git cherrypick, etc.
To fix the current situation, you can simply run git checkout master;git pull origin master.
So to make my answer more simply. Commit changes on your deateached head and make branch with this commit and then merge it together and push to master.
You can just download again your project if you didn't make changes on detached head that you need.
I am working in a team on Selenium WebDriver in Java. For eg. If I and one of my team member are working on the same file. Every time someone commits some changes into the repository and when I pull the code, eclipse shows conflicts even if a new line of code has been added to the file. Is there any way to merge both the codes without this conflict?
Maybe try to do it that way :
git add [your file]
git commit "fix"
git pull origin master
git push origin master
The conflicts may occur because you don't commit your changes before pulling from the repository.
As the title states, I'm attempting to pull from a git repository that I'm sharing between my friend and I and I can commit, he can commit, but whenever either one of us attempt to pull it brings back that it failed: DIRTY_WORKTREE
Both of us are extremely new to git, and have zero direction on how to fix this issue.
I was able to fix a similar issue by using the git command line client. While eclipse (egit) was only saying DIRTY_WORKTREE, in the command line I saw multiple conflicting files. Using git merge master from the command line, I could easily resolve the conflicts then in eclipse.
So for me this seems to be an egit issue.
Another approach, if you don't have any work in progress, is to try and reset --hard your HEAD.
With EGit: Resetting your current HEAD:
Select Team -> Reset... on a project. This opens a dialog where you can select a branch or a tag.
Reset HEAD on your current branch, in order to reset index and working tree to the last commit of said branch.
Then try your pull.
I had uncommitted changes. After I committed them, then merged, the dirty worktree issue disappeared.
Just delete the .gitignore present in the project folder, and then merge.
The merge will show conflicts , which you need to resolve and then push the changes.
It seems to mean that the version you are on now has edits that are not yet committed. So you either have to remove these edits, or commit them. Notice that if you commit them you may get merge conflicts.
This error is happening when you have made local changes to files that haven't been committed yet. In git's parlance, you have uncommitted changes in your working tree.
When you are in this situation and you try to pull, git is not sure what to do with the local changes you have. Should it discard those and pull the changes from the remote? Should it commit those before pulling the changes from the remote? That's why it fails.
To avoid this problem before you pull changes into your local repository you either have to commit your local changes, stash them, or discard them. Once you don't have pending local changes in your working tree, you should be able to pull with no errors.
In eclipse I went to Team Synchronizing View and from there right clicked on my project and hit 'overwrite' to overwrite all local changes. Then retry your merge.
Only to add another case, I've got DIRTY_WORKTREE, I'm the only one commiting to my Github project, so in EGit I did a Push branch... with "Force overwrite of branch on remote if it exists and has diverged"
DANGER: If other are working on the same project, this action will delete their commits since divergence.
I had similar problem on Eclipse with uncommited changes as ununiform.
After a commited I could merge and everything is back as it should be.
Take a look at your source code and check any changes. If none you can reset hard.
Delete the affected files and try to pull again. Thereafter push your changes to the git. I has the same issue and this worked for me.
In my case, the DIRTY_WORKTREE was caused by this sequence:
In a commit, I committed also some files that I should have ignored
In the next commit I modified the .gitignore that ignore the above files
Try to rebase on top of another branch where my change to .gitignore is missing
In this scenario, Eclipse thinks your working tree is dirty. Indeed, it is not obvious comparing two filesets when one of the two is ignoring some files and the other is not.
To solve the issue in Eclipse, I did the following:
Modify the .gitignore so it is the same as the one in the branch I want to rebase on
Happily start the rebasing or rebasing with merge.
If you have changes without commiting, eclipse will advise you if you try to pull changes. To solve it, you can discard the changes or do the commit of these files.
Source: https://www.eclipse.org/forums/index.php?t=msg&th=890477&goto=1565668&#msg_1565668
If you want to override you local branch to the origin branch.
Go to Git repo view> click on origin master> Choose reset ->it will show current HEAD and resetting to branch.
Choose HARD reset, if you want to completely overwrite your local changes
I think this problem is caused by EGit version.
When I used Spring Tools Suite with EGit 2.6, I also faced same problems.
EGit is included in STS Default package, so EGit upgrade is very difficult.
Currently I am using eclipse WTP with EGit 3.7, this problem is disappeared.
I'm working with Git in Eclipse, so every time when I tried to pull my repository the changes from my last commit does not appear in project's code. What have I missed?
Ok, I solved it with merging the remote and local branch with reducing conflicts by remote side.
I have read :
"Best practices for using git with CVS"
"How to export revision history from mercurial or git to cvs?"
, and neither suit my needs.
At work we use a remote CVS repo. Access to this repo is handled via eclipse CVS tools, and in-house eclipse plugins that are built ontop of team tools for eclipse. This means we can't move to a better vcs.
However I would like to use Git on my local machine (to enable personal branching) such that I can accomplish the following:
Create branches in Git and then once finished and merged back into my local trunk, commit back to the cvs repo using the eclipse team tools etc.
My plan is something along the following lines:
Copy the checked out files to another folder [gitRepo].
Create a master git repo in gitRepo
Branch in gitRepo and make changes.
Commit to gitRepo
Copy gitRepo back to checked out files
Sync with remote cvs.
I was planning on using eGit for eclipse however I believe that the CVS and .git files will compete for ownership of the versioning.
Are there any tools or suggested work flows to help me manage this? Also how well does Git play with CVS files. And vice versa since I don’t want them to infect each other.
The reason the former links are of no use is they commit straight to the cvs repo from the git repo and this worries me as I do not wish to infect the cvs repo by accident.
It should also be said that changes in the GitRepo do not need to persist into the CVS repo, for example I don’t need to see every push to the git repo reflected in the remote CVS.
~Thanks for reading.
You perfectly can create a git repo directly within a CVS workspace (much like directly within any other VCS tool.
Make sure git will ignore any .cvs resources, and make sure CVS will ignore the .git.
Any Git commit won't be directly reflected in CVS.
The only trick is for Eclipse to display only Git or only CVS informations and label decoration.
For that I would configure two different Eclipse perspectives in which I will de-activate one or the other VCS tool.
I have done exactly this at work and I found the following practices helpful:
Keep any one (master in my case) branch always in sync with CVS. Do not use this branch for your development. Periodically update this branch to get the changes made by the rest of the team. If these changes are relevant to your current work do a merge master from your dev (or any other appropriate) branch.
When you are ready to check in to CVS switch to the master branch and merge the changes from the appropriate branch (dev, feature etc. as appropriate). Run your tests!
You employer most likely will keep a back up of the CVS repos. You will have to find a way to keep your git repo backed up. One way is to add a mirror repository in a Dropbox folder and use a post-commit hook to update it after each commit.
Before you leave work switch to the master branch. I once made the mistake of running CVS up -d on a dev branch in the morning and ended up quite confused. Adding a script to automatically switch to master before updating helps.