0

I'm resolving a large merge conflict in a Git repository. Partway through the process, I realize that I may have resolved some conflicting files incorrectly. However, I don't remember which files had contained merge conflicts. I don't want to throw out all of my work. So how can I list the conflicted files while I'm resolving a merge conflict?

Note that I haven't committed the merge yet.

This post does not resolve my question, as it only lists files that are currently conflicted (i.e. they have the <<<<<<<<<<< markers). Stated differently, I'd like to know which files caused the conflict in the first place.

JesseTG
  • 2,025
  • 1
  • 24
  • 48
  • You can't know if there is a conflict by looking at a merge commit, for example. There's no information about conflicted files in the metadata of a commit. – eftshift0 Dec 09 '22 at 16:58
  • I haven't committed the merge yet, though. – JesseTG Dec 09 '22 at 17:05
  • 1
    Does this answer your question? [What's the simplest way to list conflicted files in Git?](https://stackoverflow.com/questions/3065650/whats-the-simplest-way-to-list-conflicted-files-in-git) – Eng_Farghly Dec 09 '22 at 19:42
  • @Eng_Farghly Thank you, but no. That lists the conflicted files after I call `git merge`, but before I start editing them. I've already edited each conflicting file, but I may have made mistakes in a few of them. However, I don't remember exactly which files were changed; nearly ever file in the project has changed in this merge (but most don't have conflicts). – JesseTG Dec 09 '22 at 22:51

3 Answers3

2

Your problem is real, but this premise is a bit faulty here:

[git ls-files -u] ... only lists files that are currently conflicted (i.e. they have the <<<<<<<<<<< markers)

The git ls-files -u output does not depend on what is in your working tree, but rather on what is in Git's index (aka staging area ). What this means for you is:

Partway through the process, I realize that I may have resolved some conflicting files incorrectly.

If you have not yet run git add on your resolved files, git ls-files -u will still list them.

Alas, if you have run git add on the resolved files, it won't. Git does have, stored in special "REUC" entries, enough information to reconstruct the conflicts, but there's no easy way to access these.

The quickest and simplest way to get a list of conflicted files—which also gets you Git's attempt at merging them—is to use git worktree add to add a second working tree at the same commit as the current commit, then re-perform the merge command in that second working tree. (The added working tree has its own index/staging-area.) For instance:

git worktree add --detach ../recreate-conflict HEAD

You can now open a new window and maneuver (or manoeuvre if you're British) to the appropriate directory and run git merge <other> there as before, or in bash, pushd ../recreate-conflict and do it in the current window.

Leave the added working tree in place as a handy consultation location until you're satisfied that you've done the merge correctly. You can leave it around as long as you want, even after committing a merge from the main working tree: it's just occupying some disk space with a checkout and the in-progress merge.

(Use git worktree remove to clean it out when you're done with it, or use the OS's "remove entire tree" option on it, then run git worktree prune. You can do either of these from the main working tree.)

torek
  • 448,244
  • 59
  • 642
  • 775
1

Here git diff with its diff-filter might be helpful

Try using

git diff --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]

A: Select only files that are Added

C: Copied

D: Deleted,

M: Modified

R: Renamed,

T: have their type (i.e. regular file, symlink, submodule, ...) changed

U: are Unmerged (U) X: are Unknow B: have had their pairing Broken .

Any combination of the filter characters (including none) can be used.

Umar Hayat
  • 4,300
  • 1
  • 12
  • 27
1

If you need more details you always can clone the project to a separate directory and start merging of the branches one more time. Or, if you are merging your local branches, would be an option to duplicate the project folder on the hard drive, then abort the merging process and start a new one. Eventually, you would have a possibility to inspect your changes more thoroughly.

Maksym Kosenko
  • 515
  • 7
  • 12
  • No need to clone — it's enough to create new temporary branches from old commits and merge them. The result can be brushed off into trash at any moment. – phd Dec 10 '22 at 11:09
  • But how to avoid a loosing of changes during conflict resolving process which are not committed yet? The author is not going to complete resolving or abort the merging process, the goal is to check right in the middle of the way. – Maksym Kosenko Dec 13 '22 at 20:00