1

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?

OfirD
  • 9,442
  • 5
  • 47
  • 90
  • 1
    Git does not record which files were part of the conflict during the merge, it only records the final snapshot. If you want to figure out which files ended up having a conflict during the merge, you will have to redo the merge or simulate the merge yourself. – Lasse V. Karlsen Oct 27 '21 at 17:40
  • @LasseV.Karlsen, can we redo the merge while still keeping the merge resolutions? So that the steps would be something like: merge > conflict > resolution > (commit? stash?) > merge again to see original conflicts > abort? Also, what do you mean by "simulating" the merge (is that different from "redoing" the merge)? – OfirD Oct 27 '21 at 17:44
  • @OfirD do you care if you commit the merge first and then look? The example in your question implies you want to see the change before you commit. – TTT Oct 27 '21 at 17:45
  • @TTT, before committing, but it seems that's not possible – OfirD Oct 27 '21 at 17:48
  • OK. I don't think you can do it with `git status`, but you can run other commands at that moment to see the superset of files that changed on `dev`, and compare it with your staged file list. Would that suffice? – TTT Oct 27 '21 at 18:09
  • @TTT, no, I guess. Comparing is tedious. When there's a merge in which dozens of files conflict (while other files changed but do not conflict), I'd like to be able to just skim through the files' names and just see the expected names there (and possibly detect anything unexpected I might have done during the conflict resolution). – OfirD Oct 27 '21 at 18:31

1 Answers1

3

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.

jthill
  • 55,082
  • 5
  • 77
  • 137