CODEWITHSUNDEEP
windowslinuxeclipsegitegit
Less
Less

Reputation: 3217

EGit - fetch, merge, pull troubles

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:

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:

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.

Upvotes: 2

Views: 1252

Answers (1)

tialaramex
tialaramex

Reputation: 3801

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.

Upvotes: 2

Related Questions