Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Git Pull is Not Possible, Unmerged Files

Tags:

git

I've read all of the similar questions on this; it seems that none of the following have worked:

Delete offending files git reset --hard HEAD git stash git pull 

Nearly every combination, stashing changes and pulling from repository, results in unmergable files. I'd like to discard all local changes and just use the remote, but I cannot clone again (bandwidth and internet usage limitations with the developer trying to do this). How do I do this?

Just tried:

git stash git pull 

Also did not work.

More Info

There is one local commit, and the upstream has a commit as well. I've thus tried git pull --rebase but it's still not working properly... That gives me errors - "exiting because of an unresolved conflict". If I do git stash, git reset --hard HEAD, git pull --rebase, I get the error "pull is not possible, unmerged changes..."

like image 693
Christian Stewart Avatar asked Feb 28 '13 03:02

Christian Stewart


People also ask

How do you fix pulling is not possible because you have unmerged files?

To fix the “pulling is not possible” error, you can use git reset –hard. Always write a commit message after adding a file to Git's history. Ensure your files are updated to avoid conflict when pulling changes. You need to commit your changes or stash them before you can merge.

Is it possible to unmerged files git?

Git Pull is Not Possible, Unmerged Files.


1 Answers

Say the remote is origin and the branch is master, and say you already have master checked out, might try the following:

git fetch origin git reset --hard origin/master 

This basically just takes the current branch and points it to the HEAD of the remote branch.

WARNING: As stated in the comments, this will throw away your local changes and overwrite with whatever is on the origin.

Or you can use the plumbing commands to do essentially the same:

git fetch <remote> git update-ref refs/heads/<branch> $(git rev-parse <remote>/<branch>) git reset --hard 

EDIT: I'd like to briefly explain why this works.

The .git folder can hold the commits for any number of repositories. Since the commit hash is actually a verification method for the contents of the commit, and not just a randomly generated value, it is used to match commit sets between repositories.

A branch is just a named pointer to a given hash. Here's an example set:

$ find .git/refs -type f .git/refs/tags/v3.8 .git/refs/heads/master .git/refs/remotes/origin/HEAD .git/refs/remotes/origin/master 

Each of these files contains a hash pointing to a commit:

$ cat .git/refs/remotes/origin/master d895cb1af15c04c522a25c79cc429076987c089b 

These are all for the internal git storage mechanism, and work independently of the working directory. By doing the following:

git reset --hard origin/master 

git will point the current branch at the same hash value that origin/master points to. Then it forcefully changes the working directory to match the file structure/contents at that hash.

To see this at work go ahead and try out the following:

git checkout -b test-branch # see current commit and diff by the following git show HEAD # now point to another location git reset --hard <remote>/<branch> # see the changes again git show HEAD 
like image 72
Trevor Norris Avatar answered Oct 06 '22 14:10

Trevor Norris