Git pull - error entry notuptodate cannot merge

Question

Hi - I am a newcomer to GIT and wanted to know how to just get a latest version of the trunk and DISCARD all of my curent changes.

All I seem to get is the notuptodate error. I do not want to save my old changes...

I also get Your branch is behind 'origin/master' by 15 commits, and can be fast-forwarded. How do I fast forward? Again, I don't care about changes I have made.

Many thanks in advance, as I the current answers on SO seems to assume you wish to keep changes

Example of error (and things that have been tried)

$ git checkout

$ git pull

Updating 69edec1..dc3fdfe error: Entry 'src/FluentNHibernate.Testing/DomainModel/Mapping/CompositeIdentityPartTester.cs' not uptodate. Cannot merge.

$ git checkout -- src/FluentNHibernate.Testing/DomainModel/Mapping/CompositeIdentityPartTester.cs

$ git pull

Updating 69edec1..dc3fdfe error: Entry 'src/FluentNHibernate.Testing/DomainModel/Mapping/CompositeIdentityPartTester.cs' not uptodate. Cannot merge.

$ git reset --hard

$ git pull

Updating 69edec1..dc3fdfe error: Entry 'src/FluentNHibernate.Testing/DomainModel/Mapping/CompositeIdentityPartTester.cs' not uptodate. Cannot merge.

FIXED: I seem to have fixed the issue by using gitk --all and using the GUI to do a hard reset on the lastest change... I would still really like to understand why the commandline wouldn't do this?

Answer 1

To throw away all your changes and go back to the latest commit, use

git reset --hard HEAD

A fast-forward is a kind of merge where there's no actual merging to do, you just have to hop along the commits. In this case, git isn't actually telling you what to do, but it's letting you know that you really ought to pull (because it would be trivial).

Answer 2

When I was new to git and often quite confused about what was going on with the branches and commits and how they were related, I found gitk very helpful for giving me an idea about what was actually going on.

For projects with not too many commits, gitk --all will give a complete overview of all commits and branches. With too many commits, that will become a little sluggish, though.

Answer 3

The git checkout -- file operation operates strictly on the working directory, or the filesystem state of your repository (note that there is a space between the -- and the file argument, to distinguish the command from checking out a branch or tag named file).

If anything has been git add-ed to the repository, in git terminology it is a part of the index, and a checkout won't fix that, you need to use the git reset command, which updates the state of the index.

As a shortcut for doing both of the above, git reset --hard will reset the index and flush out the changes in the working directory (so that your working directory and index are in identical states (the state given by an option argument; without any argument the default is HEAD). Usual caveats apply with regards to making sure you don't nuke things you want saved if they haven't been committed, but from the sounds of it this is what you want.

As for the fast-forward merge, git pull should take care of that automatically, but since in git terms a pull involves both fetching the changes from upstream and merging your local branches with the new upstream, the merge part of this will fail if you have a dirty working tree, so the above commands will need to be done (or other permutations of committing/stashing operations) before the merge can proceed. Git is in general very careful to keep you from losing work unless you specifically tell it not to care.

As a recommendation, if you want to track upstream, do so in your master branch and make any additional changes (even if you're just playing around) in a topic branch, where you can feel free to commit away and not worry about being able to absorb changes back from upstream.

UPDATE: If reset/checkout are not actually resetting your working directory, check the core.autocrlf property on your directory: git config --get core.autocrlf

If you are using a repository that makes the rounds between Windows/UNIX/whatever filesystems with different line-ending conventions, and attempts to prevent the madness that lies therein by reading files from the filesystem with a CRLF as if they had LF terminators, and then reversing that conversion when writing to the filesystem, the idea being that you can work on files normally without introducing a ton of whitespace changes into your diffs, but it often causes more issues than necessary. Try a git diff --ignore-all-space and, if it shows nothing, that's your issue, and you can try to update the config file to turn that off, and repeat.

Answer 4

First thing - thanks for the answers from everyone. It does appear to be a bug over user error. Non of the solutions suggested worked apart from gitk --all and then using the GUI to 'reset master branch here'

Not ideal but it did work.

Thanks