I have a merge remote-tracking branch 'origin/master' in my timeline with a dozen changes since then by someone else.
I can't sync. When I try to revert and git revert --continue, it says can't commit because I have unmerged files. No idea what that means.
I looked at the files in question and there are no conflict there (the git comment blocks).
Also, these filed specifically have not been modified by anyone else.
How do I just force Github to take the folder from my current local folder and just move on?
I tried deleting the repository folder and recloning, but then it saied it can't clone. Took a while just to get it to clone. But still can't sync!
Thanks!
Try stashing your changes and then syncing/merging.
git stash
git pull
git stash pop
This should merge your local from upstream and have your changes which you can commit.
Note: In some cases, this might lead to a conflict depending on your code, but that should not be a big problem to solve.
Also, unmerged means that you have files that are not committed yet. Do a git status and it should show you.
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 still learning Git's workflow for doing things, and realized that I was accidentally in the wrong working branch when I committed some files. So using EGit, I listed the commit history and selected Revert Commit from the context menu for a couple of commits.
I have since realized that I wanted those commits, but cannot find the original commits anywhere. It seems as though the original commits were all but deleted. Even doing a full log listing on the entire git repo does not show the original commit or the revert commits.
From my understanding of the EGit docs, revert commit was just supposed to "undo" the changes by creating a new commit ontop of the old one, undoing what it had done. However, it would appear that it actually deleted my original commits.
Am I toast? Did I permanently lose those changes? I'm running Eclipse 3.7 with EGit 2.1.0.20120919.
git revert, as you said, doesn't delete the commits. It only creates a new commit undoing the changes of a certain commit passed to it. So, the original commit is still in the repository. Listing the commits with git log should show the original commit and the commit that undo what the original commit does.
With that, to recover the original content of the commit, you can revert the revert commit or change your repository status to the commit before the revert with git reset --hard hash where hash represents the hash of the commit before the commits that represents your git revert.
Your best bet is to leave eclipse and egit for a while and use the commandline.
There is a tool called git reflog that can show you much more than git log. I suggest you give that a try to see what you have done to the repository.
I just made some bad commits with egit that I would like to delete.
How do I delete commits from egit?
Thanks!
EDIT: I tried a hard reset a few times but it didn't do anything.
EDIT 2: Hard reset does rollback changes indeed, but I want them to completely disappear from the history as if I never made these commits.
RightMouse on your Repository and click on "show in -> history".
You should select the last commit before your last "fetch"...most of the time its the second commit under your current HEAD.
RightMouse on that commit and "reset -> Hard" (will reset all your commits AND local workspace changes to the selected commit).
you should see the up-arrow changing into an down-arrow, meaning that your commits are deleted and that your repository is outdated. Use "fetch" & "rebase" to be up to date.
Note that Egit3.0 in Kepler allows you to hard reset to any treeish expression you want:
But once hard reset, you still need to git push --force after that: if you don't the history of your upstream repo would still list that commit.
You can do a hard reset but be carefull with that !! Here's some more info: Delete commits from a branch in Git
I wanted to rollback to the last commit after making a massive error, but I managed to rollback a little too fair. The commit I wanted to reassert doesn't appear when I enter 'git log' in bash (I suppose because it's no longer in the history). Is there any way I can recover the last commit by date?
I'm also using eGit in eclipse for the same project if that makes things easier. Thanks.
If you are ok with command line, go to you repo, do a git reflog and get the commit which you want to "rollback" to and do a git reset --hard <commit>
You would also be able to do git reset --hard HEAD#{1} and then come back to egit and rollback to the desired commit.
I find that generally it's better to make your changes forward in time rather than backward.
Git's approach is to "revert" the commit. When you revert a commit, you check out into your working directory the inverse of the commit in question. Then you add and commit that, and you've just made a NEW commit, that commits the "undoing" of the commit you're reverting, AND it leaves a record in history that such a thing happened, so if you want to undo your undoing, it's easy to do.