OK, here’s the deal.
I have Git installed on my Debian (lenny) remote server. Git version there is 1.5.6.5. I intend to use it as a remote shared/backup repository.
My development machine is running Windows, where my Eclipse with EGit is. So, this is what I did:
- Created shared user for git.
- Set up the SSH (in Eclipse and on the server), exchanged public keys, etc, all went well.
- I created remote repo and initialized it with git –bare init.
- Created project in local repo, did a couple of changes and commits, successfully.
- Pushed master branch from local repo, to remote master. So far so good.
- (In addition, on a third machine, I cloned the remote repo (through EGit import) without any problems, whatsoever.)
The “strange” stuff began when I deleted a couple of files from project, commited, and then tried to pull from remote, expecting to restore deleted items, since the last snapshot that was pushed to remote had all the files. Since pull is essentially fetch + merge , seems that EGit has some known issues regarding the merge strategy. Nevertheless, I configured fetch, resulting in following fetch specification:
refs/heads/master:refs/remotes/amrtest1/master
Fetch went OK, at least it seemed so, new folder was created in the local repo for the remote master branch, and I noticed FETCH_HEAD is there as well.
With checked-out local master branch I tried merge with the remote master… The result was:
- Locally deleted files were not restored.
- in the Synchronize perspective, I could see the missing files (in the outgoing mode?)
- In the history view of EGit, the action of fetching was chronologically before the local commit (after deleting files), which is certainly not correct.
Am I doing something wrong here? Are my expectations of restoring the state invalid, based on the described process? If so, what would be the way to go (to restore the state form remote repo, or at least merge it correctly with existing local)?
Thanks.
Yes, your expectation is wrong. In fact it took several re-reads before I grasped that you believed Git would somehow psychically detect that you didn’t want to delete the files which you had explicitly deleted and restore them during the merge operation. If you want the files back you ought to either revert the commit which removed them, or copy the files from the version where they existed into your current version.
On top of that, if you are correct about what you’re calling the “history view of EGit” it probably means you’ve set pull to perform rebase instead of merge anyway. In rebase it’s roughly assumed that your changes since the last pull should be applied as if against the current version of upstream. This is often cleaner for others to understand, but can be confusing or fail outright if many people are changing the same or related code in that time.