Doesn't find merge conflicts tags in open file

[msheaver]

When I run this on an open file that has merge conflicts (see attached), it doesn't find them. Is there something I am doing wrong here?

[smashwilson]

Is git aware that the file has conflicts, or is there a chance it was erroneously marked as resolved?

Try running git status (and git status --porcelain) at the command-line to check. If the path in question is showing up as conflicted and the package just isn't detecting it, paste the git status --porcelain output here and I can try to figure out why it isn't.

[msheaver]

Hi Ash,

Thanks for the quick k reply; my guess is that is was indeed marked as resolved by the GUI I am using. I am using SourceTree on a Windows 7 desktop (work) and am getting some really strange behavior. I would add a single contiguous block of code to my clean file Git-wise and it would cause a whole host of merge conflicts on that file. I have never encountered such craziness using Git on my home Mac; this causes me to suspect that something in Windows is causing this.

I will try your suggestions below tomorrow and let you know how it goes.

Cheers, Michael

On Dec 28, 2015, at 9:55 AM, Ash Wilson notifications@github.com wrote:

Is git aware that the file has conflicts, or is there a chance it was erroneously marked as resolved?

Try running git status (and git status --porcelain) at the command-line to check. If the path in question is showing up as conflicted and the package just isn't detecting it, paste the git status --porcelain output here and I can try to figure out why it isn't.

— Reply to this email directly or view it on GitHub https://github.com/smashwilson/merge-conflicts/issues/196#issuecomment-167584031.

[yskkin]

I have same problem and git is indeed aware of conflict.

git status
On branch feature/xxxxxx
Your branch is ahead of 'origin/feature/xxxxxx' by 2 commits.
  (use "git push" to publish your local commits)
You have unmerged paths.
  (fix conflicts and run "git commit")

Changes to be committed:

    modified:   View/xxxxxxx
    modified:   webroot/xxxxxx

Unmerged paths:
  (use "git add <file>..." to mark resolution)

    both modified:   View/yyyyyyyyy
    both modified:   webroot/yyyyyyyy

git status --porcelain
UU View/yyyyyyyy
M  View/xxxxxx
M  webroot/xxxxxx
UU webroot/yyyyyyyy

The package is detecting paths in conflict panel, but highlighting is not performed.

[SerbanC]

Same problem. The plugin worked fine for the first several times, then started failing consistently. The files are definitely in conflict. This takes away most of the appeal of the plugin, since the only functionality left is file detection which isn't hard to do. Hope it gets fixed sooner rather than later.

[ghost]

I'm also having this issue. Seems very inconsistent in terms of when it fails and when it works. I can't pin it down to a conflict with any particular package. But it does seem to work 100% of the time when all community packages are disabled.

[SerbanC]

I checked all my community packages and, in my case, it is indeed because of EditorConfig, as mentioned in #202. My full list of packages is:

emmet
file-icons
highlight-selected
imdone-atom
language-babel
language-nunjucks
language-vue
linter
linter-esline
merge-conflicts
pigments
tabs-to-spaces
editorconfig

With all of them enabled except Editorconfig, it's working fine. I'll check for/submit an issue on that repo.

[smashwilson]

Interesting. Thanks for doing the detective work to narrow it down!

I wonder what the conflict is? I'll watch the other issue to see if it's something that needs to be fixed on this end...

[smashwilson]

My first thought is that some of the normalization that it's doing is interfering with the regexp we're using to match conflict areas, but we are already handling \r\n... hmm.

[hellochar]

I'm seeing it consistently fail. When I click the erroneous file after alt-m d the file appears and flashes the green/blue highlights in the appropriate places for a split second, then immediately disappears. The hotkeys and commands don't work either, and git is aware of the merge conflicts

[dpo]

Same issue. No conflict detected. Git is aware of them because I'm in the middle of a rebase.

[ardhipoetra]

Reporting of same issue here. I don't have editorconfig package with me. So the culprit may be something else. I tried to disabling all of my community package but still not working

[erikdonohoo]

I have the same issue. I have editorconfig installed as well, but even with ALL my community packages disabled, I still have the problem. For me, it is fixed if I immediately quit and restart the package. It only fails when I turn it on, and then click a file name in the gutter to open it to view the conflicts. It shows the highlighting briefly and then fails. Here is what I am seeing

EDIT

After hard closing atom, and reopening (with editorconfig disabled) it does work as expected. However, even with editorconfig enabled, I can do what you see in the gif to get it to work. Essentially the files that have conflicts need to be open already before you detect the changes, and then it works

[smashwilson]

After hard closing atom, and reopening (with editorconfig disabled) it does work as expected. However, even with editorconfig enabled, I can do what you see in the gif to get it to work. Essentially the files that have conflicts need to be open already before you detect the changes, and then it works

If you disable or update editor-config, you will need to fully quit and re-open Atom for the change to take effect; otherwise, the conflicting callback will remain registered.

It appears that sindresorhus/atom-editorconfig#79 should correct our problem. Can any of you:

• Install editor-config >= 1.3.0 (it looks like 1.4.0 is the latest)
• Fully quit and restart Atom
• Verify that conflict detection is working properly now?

[smashwilson]

Reporting of same issue here. I don't have editorconfig package with me. So the culprit may be something else. I tried to disabling all of my community package but still not working

@ardhipoetra, are you on Windows? #227 may be the same issue that you're encountering.

[ardhipoetra]

nope, I'm in Ubuntu 16.04. With (currently) atom 1.7.2

[garygreen]

Bump. I'm getting the same problem, "No conflicts here" on version 1.4.5, on Windows 10. There definitely is conflicts as git status --porcelain is showing

UU src/Http/Controllers/GalleryController.php

Restarting atom has no effect. Very frustrating !