Pulling commits after fixing a merge conflict says that there are conflicts left to resolve

[ImRodry]

Describe the bug

If you have a merge conflict in your repository either by merging from a branch into another or by restoring stashed changes (my situation) and you fix them, you will get an error when pulling commits from the repository saying that there are conflicts left to resolve. This is obviously not true since you have fixed them and the affected file(s) have a green tick next to them

Version & OS

GitHub version 2.7.2 and Windows 10 version 20H2 build 19042.870

Steps to reproduce the behavior

1. Create a merge conflict in your working repository. This can easily be done by changing a file, stashing it then committing changes to that same file (and lines) and restoring the stash
2. Have someone else send a commit to your repository (or make one yourself through a source other than GitHub Desktop)
3. Click the pull origin button.
4. You should get an error saying there are merge conflicts left to resolve which doesn't let you pull the commits

Expected behavior

You pull the commits properly without any issues

Actual behavior

You're not allowed to pull the commits from the source due to the aforementioned bug

Screenshots

Unfortunately, I couldn't get a screenshot of the message, will do if it happens again.

Logs

2021-04-07.desktop.production.log The bug can be found at 20:01:04

Additional context

The files in my working tree were completely different from the changed files in the commit I was trying to pull, so I believe the issue didn't come from that.

[sergiou87]

Hmmm weird, I don't see how this is a GitHub Desktop specific error. What happens if, at step (3), you enter git pull from the terminal instead of pulling from GitHub Desktop? Do you get the same result?

[ImRodry]

Not sure since I'm not too familiar with Git itself but I will try to reproduce that and will let you know if I manage to succeed

[ImRodry]

Can confirm the issue does happen when executing git pull. What would be the best way to go on about this issue then?

[sergiou87]

@ImRodry can you run git status in that state and share a screenshot of both the terminal and GitHub Desktop?

I'm curious about whether Desktop is reflecting the same state as git status 🤔

[ImRodry]

Here I ran the command three times: the first time the merge conflict showed up as resolved on GitHub Desktop, the second time it was unresolved (I undid the changes) so it displayed a warning sign, and on the third command there were no merge conflicts. Hope this helps!

[sergiou87]

Thank you!! I still wonder what does GitHub Desktop show in step (3). Could you do this?

1. Create a merge conflict in your working repository. This can easily be done by changing a file, stashing it then committing changes to that same file (and lines) and restoring the stash
2. Have someone else send a commit to your repository (or make one yourself through a source other than GitHub Desktop)
3. Take screenshot of GitHub Desktop
4. Run git status from the terminal
5. Take screenshot of the terminal

That would be super helpful to better understand what GH Desktop thinks of your repo vs git status at step 3 😄

Thank you again for your help!

[ImRodry]

When the merge conflict has been resolved, GitHub desktop will show a green tick next to the file saying "Resolved" when you hover it. The terminal displays what I showed in the previous comment saying "both modified" on the conflicting file whether the conflict has been resolved or not.

[sergiou87]

Yeah in that case GitHub Desktop is not adding it to the stage, so you can't pull, you must commit the change first (or stash it again) before pulling.

In any case I'd say this is expected behavior and not a bug in the app, sorry!

[ImRodry]

Well it doesn’t let me stash either because of the “merge conflict” it thinks I have. Where would be the appropriate place to report this? I’m not sure how to report bugs with git itself

[sergiou87]

I don't think it's a bug at all:

• On the git side, you can either git add or git reset to solve the conflicts or clear the changes, and then pull.
• On the GitHub Desktop side, you need to either commit the change or discard it before pulling. I thought stashing would work though, that might be a bug 🤔

[ImRodry]

But then why doesn’t git detect that the conflict was resolved? Is it because it needs to be committed or is there a way to resolve without committing? Also the reason you can’t stash changes is the same reason why you can’t pull commits: the non-existent merge conflict

[sergiou87]

That's because GitHub Desktop is kind of disconnected from what git sees, in order to be able to abstract some git stuff and try to make the experience simpler to our users overall. But as you can see, it's not perfect 😅

An example of this is when you have all your changed files marked to be included in the next commit: you might think they are also in the stage ready to be committed using git from the command line (i.e. they show up in green when you run git status), but they're not (they show up in red).

If you committed that change, Desktop would automatically add the file (which would effectively mark it as resolved) and then make the commit. However it doesn't do anything like that with pull or stash.

I think maybe you're right and despite the fact this is kind of expected, there might be room for improvement in terms of how to handle this scenario. I'm gonna reopen the issue and mark it as a bug. Sorry for keeping you going back and forth about this!

[ImRodry]

No problem! I actually don't use git at all so I never noticed the bug you mentioned but I understand what you meant. If you want you can feel free to also change the title of the issue so that it's a more accurate description of the bug itself. Thanks for the explanation :)

[Sweater-Baron]

I just ran into this issue with not being able to stash the changes as well (wanted to switch branches).

I was able to solve it by just committing the files, and then running git reset --soft HEAD~1, after which Github Desktop didn't consider there to be any unresolved merge issues anymore and treated the files as normal, stashable uncommitted changes.

It definitely seems like a bug that stashing is not possible in this situation (or at least I don't understand why it's the case)

[ImRodry]

What I usually do to fix this is staging all files and then unstaging, which marks the issues as resolved and let's you do anything if you're looking for a quick workaround (since committing can sometimes take a while)

[steveward]

Two reports of this in https://github.com/desktop/desktop/issues/13756.

[sergiou87]

Another report in #14467

[Justin-JHG]

What I usually do to fix this is staging all files and then unstaging, which marks the issues as resolved and let's you do anything if you're looking for a quick workaround (since committing can sometimes take a while)

yes the thing is that you cannot staging/unstaging files within Github Desktop, which defeat the original design of Github Desktop imo as it was trying to make users feel that there is no concept of staging area. So imo anything that requires to do outside of Desktop needs to treat as a bug unless it's a new feature not supported by it yet.

[ChrisJamesonGroves]

Looks like there is no progress on resolving this, and I have hit this issue again.

Interestingly, when I merged the conflicts and saved the file I get the Green tick in Github Desktop which I would assume is all ok and its here where I cant do anything because GH Desktop says there are still unresolved conflicts! When I look in Windows Explorer I see that that file still has an "!" exclamation mark icon. If I right click and open in VSCode there is a button which I'm sure wasnt there when I resolved the issue originally which was something like "Resolve in merge editor". Clicking this the Exclamation mark goes and in GH Desktop there Green tick is also gone and shows the orange Modified icon. This now allows me to continue merging or stashing as I would expect.

So it seems like maybe there is a difference between fixing the issues in the code (resulting in the Green tick) and marking the file itself as resolved (resulting in the Modifiy icon) which is where you want to be to continue.

Also the missing "Resolve in merge editor" button is a reported issue: https://github.com/microsoft/vscode/issues/171730

[Zuur]

I'm still getting this error and not sure this should be closed?

If you're just using GitHub Desktop, resolve a conflict normally, then pull some more changes, you get in a position which can't be resolved from within GitHub Desktop, because GitHub Desktop seems to be reading the conflict state wrong?? (it's showing as a green tick but then tells you there's a conflict so you can't do anything).

[cmilette62]

Apparently this is still not fixed. For something that was reported almost 3 years ago, you'd think it would get some attention. So how would I be able to perform an update from the main development path into my local copy using the command line? Everything I read in the manual seems to merge into the main development path. I know I have problems with my code and I need to update with the main path since it's been a while, before I commit my changes.