When a git merge conflict is resloved by keeping the current branch version, no files are listed when running git status, because no files were changed.
Of course, if however the other branch version is selected to resolve the conflict, changes are listed.

Is there a way to see the files that took part in the merge conflict, after it was resolved (and before it's committed), regardless of changes?

Demonstration

The following is a pretty much full reproduction to get to what I'm talking about:

Say we have:

• A master branch, with a file named t.txt.
• A dev branch that was branched out of master (so dev also has t.txt).

Now, let's create a conflict:

$ git checkout dev
$ echo test1 > t.txt
$ git commit -am "test1"
$ git checkout master
$ echo test12 > t.txt
$ git commit -am "test12"
$ git merge dev

The output of the last line is:

Auto-merging t.txt
CONFLICT (content): Merge conflict in t.txt
Automatic merge failed; fix conflicts and then commit the result.

Now, let's edit the file to resolve the conflict:

Before edit:

$ nano t.txt

<<<<<<< HEAD
test1
=======
test12
>>>>>>> dev

Let's resolve the conflict by deleting devs version in the editor. Hence, after edit:

$ cat t.txt

test1

And now:

$ git add .
$ git status
On branch master
All conflicts fixed but you are still merging.
  (use "git commit" to conclude merge)

However, if instead of resolving the conflict by keeping master's version we would have went with dev's version, like so:

$ cat t.txt

test12

...Then the changed files would have been listed:

$ git add .
$ git status
On branch master
All conflicts fixed but you are still merging.
  (use "git commit" to conclude merge)

Changes to be committed:

        modified:   t.txt

So, going back to my question, I'd like to somehow list t.txt in any case it was part of a resolved merge conflict. Can it be done?

CodePudding user response：

So, going back to my question, I'd like to somehow list t.txt in any case it was part of a resolved merge conflict [even before committing the result the first time]. Can it be done?

Git doesn't have a redoable "undo" for merge conflict resolutions, but fortunately if you're happy with your engineer's hat on it's easy to see what was there before without hurting anything:

scratch=`mktemp -d`
git worktree add -d $scratch @
cd $scratch
git merge MERGE_HEAD    # with whatever options you used before

and you've recreated the original conflicted state. cd back and git worktree remove $scratch when you're done looking.

The only case I can think of that's not possible to recreate is if you run with rerere on and you've run rerere manually since resolving and you want to see what the results would have been if you hadn't done that, I think nobody's taught Git how to handle that yet.

Edit: by the way, if checkout is painful enough that you're willing to dance a little to avoid it, there's this thing Git can do called "minimum-checkout merging" that only checks out the files that need some sort of merge resolution. It's ... insanely fast. Google didn't rank my answer about this very high so here's a link, and ... well, that's almost as simple as the worktree solution.

git clone -ns . `mktemp -d`
cd $_
git reset -q
git merge $(git -C $OLDPWD rev-parse MERGE_HEAD)
git ls-files -u | uniq

and you've got your list of conflicted fils. That scratch clone will very probably be so small you can just abandon it and let the system clean it out whenever, but if you're feeling fastidious you can just delete it, cd -; rm -rf $OLDPWD when you're done.