Han-Wen Nienhuys wrote: > Jakub Narebski escreveu: > >> Graham Percival wrote: >> >>> 84219bb don't have input/templates/ any longer. >>> fatal: Entry '.gitignore' would be overwritten by merge. Cannot merge. >>> No merge strategy handled the merge. >>> >>> As a git newbie, I'm quite confused. OK, there's no merge strategy... There is no merge strategy used, because problem (conflict) doesn't stem from what was committed, but from what was in working directory. >>> so what do I do now? With cvs, the changes would be dumped into the >>> file. I look at the file, found the conflict, and tried it again. I >>> got the same error message, and then it occurred to me that although I >>> changed the files in my ~/usr/src/lilypond, git might be storing these >>> files somewhere else. >> >> Yes, the git error messages certainly needs to be made more user-friendly. >> What git says here that one version has '.gitignore' file handled by version >> control, and second has it outside version control. At least I think what >> it does. > > Which is actually not true. .gitignore has been in the repo since we > started using git. I have also seen this message pop up a few times > in the beginning, but I can't recall why they happened. I don't know if git allows to pull into dirty tree with impunity. If I remeber correctly Cogito (alternate UI for git) allows this[*1*], there is currently work on this in git (but it is not as far as I remember in git 1.4.4.1). So another possibility is induced by CVS "update then commit" mentality pulling changes _before_ commiting changes. If this is the case, committing changes _then_ pulling would solve this problem. Footnotes: ---------- [*1*] This is a bit error prone. -- Jakub Narebski Poland - 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