Part of the problem is deciding how to represent the <whitespace> conflict for such non-printable characters for such merge conflicts.
At the moment there are no good ideas about what whould be inserted into the file as a conflict marker, and how then it would be handled. If you have any good ideas for that then it may be worth a discussion on the main git list (and probably the Git for Windows dev list as well). Part of the problem is that even once a suitable display format is decided for the conflict marker, we would still have the 'competing editor' issue where Git's internal diff would be making one EOL assumption and your editor still happens to have the alternate EOL assumption when you remove the conflict markers, but leave in that un-see-able extra (or missing) part of the EOL sequence (and the problem reappears/repeats). There is a patch just being developed on the main Git list that will report on the various conventions in use for: the file in the file system, the file in the index/staging area, and the file in the repo, and what the config/attributes says it expects it to be (that's four different ways!). >From this week's "What's cooking": * tb/ls-files-eol (2015-11-28) 2 commits - convert.c: mark a file-local function static - ls-files: Add eol diagnostics Add options to ls-files to help diagnose end-of-line problems. This latest round hasn't gotten any review yet. Waiting for review. -- I'm sure that a user feedback would help, even if only to (thoughtfully) concur as to its likely usefulness. http://thread.gmane.org/gmane.comp.version-control.git/281785/focus=281797 Philip ----- Original Message ----- From: Quentin Neill To: Git for human beings Cc: wor...@alum.mit.edu Sent: Friday, December 04, 2015 4:24 PM Subject: Re: [git-users] Merge conflict error, when there was no change in mentioned file Hi Philip,, This is an area of interest to me, any headway on this? I would suggest some extra output be added about *why* files conflict when "git-merge" is run with -v In the past I noticed not much difference between "-q, [nooption], and -v" in the output. -- Quentin On Sunday, May 17, 2015 at 6:47:22 PM UTC-5, Dale R. Worley wrote: "Philip Oakley" <philip...@iee.org> writes: > I think in this case the byte by byte check was identical,including line > endings, which made it all the more awkward to sort out. (detecting file > mode changes!) Oh, that's interesting. Internally, it means that the recorded hash for files matches between versions, but the recorded hash for the directories won't be (because the files' modes are stored in the directory object, not the file object). Dale -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
