I use VS CODE for version control (using git).
Every time I had a conflict, VS CODE showed me with a layout where I could see all the changes in one window:
However, with no advice, it change to a weird 3 windowed design where I can’t understand anything.
Does someone know how can I go back to the first design?
5
Answers
This feature (3 way merge editor) can be enabled by setting
git.mergeEditor
totrue
and will be enabled by default in future releases.You can set it back to
false
to go back to the previous design as you want.Now you should be able to see the previous merge layout.
This new 3-way merge editor seems to have a terrible UX issue. For me simply switching to merge editor to ‘false’ doesn’t work as below:
After this editor completely stopped showing me any merge conflict line.
I have to finally do like this to revert back to original merge conflict view.
Hit
ctrl
+shift
+p
to open command pallet and open the settings json by typingPreferences: Open User Settings (JSON)
(or start typing ‘settings’ and this will come up)In the main JSON object add
"git.mergeEditor": false
(insert comma beforehand if needed)Hit
ctrl
+shift
+p
and typeDeveloper: Reload Window
to reload the windo.The old type of merge editor should be back.. but you may need to wait a minute to get the full UI back (on my machine, the
accept incoming
buttons etc. didn’t come back for a little).Update 2023 in case the conflict UI has crashed/not displayed
When you rebase a file with embedded conflicts within conflicts VScode’s in- file-conflict-display(blue/green UI) might glitch due to too-many git markers present, rendering merge impossible without CLI.
Apply workaround by enabling and switching to 3 way conflicts window.
enable merge editor (by searching the settings or modifying vscode config file locally)
use vscode’s merge display by going to Source Control tab then clic the file with ! exclamation mark before the name of the file
solve the maximum number of conflict using the new 3 windows conflict UI (remember current and incoming are inverted in case of rebasing)
go back to normal file UI and the classic in-file-conflict-UI (green/blue) should be back online
finally
git add .
&&git rebase --continue
&&:wq
(vim) in case of rebase to pass to the next commit to handle.Rule of Thumb: Remember to always create a temporary local branch of your feature before merging/rebasing your feature branch before PR. This will be used as backup to keep the design intent in mind. Then always run code(and lint) to check for obvious typos/merge artifacts (ie these git flags or unclosed loops/functions).