Merge hint count doesn't match actual conflicted files
See original GitHub issueThe merge hint indicated there will be more conflicted files than what was showed in the actual merge conflict modal.
From four to three:
Reproduction may be difficult.
In command line:
Unmerged paths:
(use "git add <file>..." to mark resolution)
both added: UnitTestProject1/UnitTestProject1.sln
both added: UnitTestProject1/UnitTestProject1/Properties/AssemblyInfo.cs
both added: UnitTestProject1/UnitTestProject1/UnitTestProject1.csproj
tested in 1.5.0-beta3, mac
Issue Analytics
- State:
- Created 5 years ago
- Reactions:2
- Comments:17 (17 by maintainers)
Top Results From Across the Web
Would resolving Git merge conflicts always mean adjusting ...
I'm learning Git from here and don't see how resolving conflicts can be anything other than changing your files to match that of...
Read more >Git: Guide to Solving Merge Conflicts - Stack Abuse
In this guide, we'll take a look at how to resolve a Git Merge Conflict when pulling from, pushing to or merging changes...
Read more >Troubleshoot common coauthoring errors - Microsoft Support
Sometimes you'll see an error in Word when coauthoring with others. Here are some quick tips to get back on track. WindowsmacOS.
Read more >Comparing and merging text files - WinMerge 2.16 Manual
This topic describes how to use the WinMerge File Compare window to compare and merge text files. To understand the basic concepts about...
Read more >Commits are snapshots, not diffs - The GitHub Blog
Git iterates through each added file and compares that file against each deleted file to compute a similarity score as a percentage of...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
In working through the equivalent feature for the rebase flow I’ve stumbled upon an escape hatch that might mean we don’t need all that complexity from the proposed fix.
I’m currently testing the use of a worktree in a temporary directory to perform the merge . This means we could update the working directory using the exact same merge steps we use in the app, avoiding the need to use
git merge-tree
and then trying to cobble together the missing information thatgit merge-tree
overlooks.Based on my testing of #7445 I think the learnings and tools from there could be reused here. Stay tuned.
A theory that I’d like to unpack and explore (given a couple more real examples that I can test against) would be to test in two stages:
git merge-tree
to find files that have been modified in both branches and cannot be merged automagicallygit diff-tree [merge-base]..[branch]
for the base branch and the compare branch and filter on paths that will trigger the sort of conflict thatblegh-test
shows.Why
git diff-tree
? This is a convenient way to see which paths have been changed on each branch, and shows the relevant context I think I need here:Here’s the output for the previous merge scenario:
We see that each branch has made changes to the same two entries:
README.md
is modified in one branch but deleted in the other - I think that’s the detail I’m missingasuperlongfilenamethatnoonewouldeveruseexceptmaybetheywould.md
is added in both with the same blob - if these differed content-wise I believegit merge-tree
would try and merge the content and provide this detail tostdout
.