2

I've googled this in many different ways and can't find anyone else talking about it (at least as far as I understand).

On my office pc I was trying to find a solution to a problem I was having (so I was ahead of my remote git repo, but without committing). That night at home I figured out the solution and pushed it to my remote repo from my home pc.

Now I'm back in work and I wanted to reset my local repo on my office pc to match the remote (and discard all my local changes).

I ran: 

git reset --hard origin/branch1

I got:

HEAD is now at 1501f25 **Still trying to merge**

What does this mean?
'Still trying to merge' seems to indicate it didn't complete somehow, but I can't see how (and I'm having no luck finding a clear answer in the git docs).

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
roy collings
  • 31
  • 3

1 Answers1

0

If a git merge --abort (git1.7.4+, January 2011) doesn't do it, check if you still have a .git/MERGE_HEAD file (and delete it).

Then the git reset should proceed (or, since it completed, the git repo state should be coherent).
Make sure you are in the right branch you wanted to reset to origin/branch1.

As the OP Roy Collings suggests, recloning should get rid of the warning, but that means having one's project config files versioned in order to minimize the time spent to configure everything again in a new cloned repo.
Since relative paths are supported in an Eclipse config, having .project and .classpath in a git repo is possible.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Hi VonC - I gave that a go, but at the "merge abort" I got: "fatal: There is no merge to abort (MERGE_HEAD missing)." I guess could just remove it all and clone it again, but that seems a bit harsh (and I'd have to juggle my Eclipse .project files). – roy collings Jul 15 '13 at 07:18
  • @roycollings not if you include `.project` and `.classpath` in your repo ;) See http://stackoverflow.com/a/17260284/6309 – VonC Jul 15 '13 at 07:21
  • I can't ... well okay, I can :), but we're a mix of devs working on the master repo (which we fork / pull request / etc..) using different IDE's and workspaces so it's something I'd rather avoid. – roy collings Jul 15 '13 at 07:23
  • @roycollings but we are talking about just *your* repo, right? So either cloning that *one* repo (to get rid of the error message), and changing a few paths in your `.project`/`.classpath`, or taking this issue as an opportunity to set uniform path policies for all to use. – VonC Jul 15 '13 at 07:25
  • Mmm - I am considering this after reading the discussion your link points to there (got some very good points in it). But the fact it's just my repo becomes moot once I submit a pull request to the 'live' repo. Then it become the base that everyone else 'pull upstream's from before making their changes. – roy collings Jul 15 '13 at 07:29
  • @roycollings is it possible to: 1/ clone it and check the warning is gone. 2/ replace the origin repo by the cloned one? That would mean no change whatsoever, for your settings, or for your colleagues cloning your repo. – VonC Jul 15 '13 at 07:30
  • Indeedy! I've done that and all's well now - thanks @Vonc, I'm going to consider including .project and .classpath / standardizing the paths etc... a bit more too I think. Maybe it would actually be less of a problem than I first thought. – roy collings Jul 15 '13 at 07:37