"Pelle Svensson" <pelle2004@xxxxxxxxx> writes: > 8. git-pull <- Problem! And the problem is...??? > Accidentally I had 2 files not committed and one of these also > had changes in the git-pull master branch which git could > not merge automatically. So you had changes to fileA that you already committed, and further changes in your working tree, and Linus side updated that same file since you started working on it? If that is the case, I suspect that the pull stopped saying something like "Entry ... not uptodate. Cannot merge." If that is the case I think your working tree has what you had before you started the pull. Deal with your own changes in the files you dirtied (say, commit them first) and pull again. Otherwise, what happened was you had changes to fileB that you already committed, and Linus side also updated the same file in the meantime, and you did _not_ have any change to that fileB in your working tree (you might have had some other files locally modified). And the pull would have reported something like "CONFLICT (content)" in such a case. $ git diff will show you an output that looks like diff but not really (you can tell by its hunk header that have three '@' letters instead of normal two); you have a conflicted merge result, and have the usual conflict markers in that file. Edit the file to resolve conflict. Then say: $ git update-index conflicted-file-1.c conflicted-file-2.c ... $ git commit to record the merge commit. Do not update-index the files that you had your own changes before pulling -- those changes do not have anything to do with this merge and you do not want to record them as part of the merge. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html