inger
inger

Reputation: 20184

What's the simplest way to list conflicted files in Git?

I just need a plain list of conflicted files.

Is there anything simpler than:

git ls-files -u  | cut -f 2 | sort -u

or:

git ls-files -u  | awk '{print $4}' | sort | uniq

I guess I could set up a handy alias for that, however was wondering how pros do it. I'd use it to write shell loops e.g. to auto-resolve conflict, etc. Maybe replace that loop by plugging into mergetool.cmd?

Upvotes: 959

Views: 684025

Answers (24)

mda
mda

Reputation: 1186

git status --short | grep "^(.U|U.|AA|DD) "

Upvotes: 22

JulienW
JulienW

Reputation: 199

This seems to work fine:

git status --porcelain=2 | grep ^u | awk '{ print $11 }'

In the porcelain format v2, a line for an unmerged paths starts with a "u". It's also designed to never change with a new version, so it's suitable for a script.

Upvotes: 0

Hashim Aziz
Hashim Aziz

Reputation: 6062

Git marks conflicts in a file using "conflict markers", which IDEs like VS Code use to visually highlight the conflicts:

<<<<<<< HEAD 
original code
======= 
merged code
>>>>>>> merged_branch

You can find all files that still have conflict markers (i.e. all files you've yet to resolve conflicts for) using:

git diff --check | grep -i "conflict" 

Upvotes: -1

user9869932
user9869932

Reputation: 7337

You could try

$ git status | grep both

a sample output would be:

    both modified:   package.json

Upvotes: 1

z atef
z atef

Reputation: 7679

Just read man page for git status, and filter what is needed.

 git status --help

Snippet:

       For paths with merge conflicts, X and Y show the modification states of each side of the merge. For paths that do not have merge conflicts, X shows the status of the index, and Y shows the status of the work tree. For untracked
   paths, XY are ??. Other status codes can be interpreted as follows:

   •   ' ' = unmodified

   •   M = modified

   •   A = added

   •   D = deleted

   •   R = renamed

   •   C = copied

   •   U = updated but unmerged

   Ignored files are not listed, unless --ignored option is in effect, in which case XY are !!.

       X          Y     Meaning
       -------------------------------------------------
                [AMD]   not updated
       M        [ MD]   updated in index
       A        [ MD]   added to index
       D                deleted from index
       R        [ MD]   renamed in index
       C        [ MD]   copied in index
       [MARC]           index and work tree matches
       [ MARC]     M    work tree changed since index
       [ MARC]     D    deleted in work tree
       [ D]        R    renamed in work tree
       [ D]        C    copied in work tree
       -------------------------------------------------
       D           D    unmerged, both deleted
       A           U    unmerged, added by us
       U           D    unmerged, deleted by them
       U           A    unmerged, added by them
       D           U    unmerged, deleted by us
       A           A    unmerged, both added
       U           U    unmerged, both modified
       -------------------------------------------------
       ?           ?    untracked
       !           !    ignored
       -------------------------------------------------

Upvotes: -4

CB Bailey
CB Bailey

Reputation: 791849

Use git diff, with name-only to show only the names, and diff-filter=U to only include 'Unmerged' files (optionally, relative to show paths relative to current working directory) .

git diff --name-only --diff-filter=U --relative

Upvotes: 1632

Mariusz
Mariusz

Reputation: 386

For me the accepted answer didn't work. To prevent from capturing

warning: LF will be replaced by CRLF in []. The file will have its original line endings in your working directory

In Powershell I used this instead:

git ls-files -u| ForEach{($_.Split("`t"))|Select-Object -Last 1}| get-unique

Upvotes: 0

Deniz da King
Deniz da King

Reputation: 401

I would also suggest the following command if you are working on a local git repository or in a directory in which patch -p1 --merge < ... was applied.

grep -rnw . -e '^<<<<<<<$'

Upvotes: 6

Reed
Reed

Reputation: 14974

The answer by Jones Agyemang is probably sufficient for most use cases and was a great starting point for my solution. For scripting in Git Bent, the git wrapper library I made, I needed something a bit more robust. I'm posting the prototype I've written which is not yet totally script-friendly

Notes

  • The linked answer checks for <<<<<<< HEAD which doesn't work for merge conflicts from using git stash apply which has <<<<<<< Updated Upstream
  • My solution confirms the presence of ======= & >>>>>>>
  • The linked answer is surely more performant, as it doesn't have to do as much
  • My solution does NOT provide line numbers

Print files with merge conflicts

You need the str_split_line function from below.

# Root git directory
dir="$(git rev-parse --show-toplevel)"
# Put the grep output into an array (see below)
str_split_line "$(grep -r "^<<<<<<< " "${dir})" files
bn="$(basename "${dir}")"
for i in "${files[@]}"; do 
    # Remove the matched string, so we're left with the file name  
    file="$(sed -e "s/:<<<<<<< .*//" <<< "${i}")"

    # Remove the path, keep the project dir's name  
    fileShort="${file#"${dir}"}"
    fileShort="${bn}${fileShort}"

    # Confirm merge divider & closer are present
    c1=$(grep -c "^=======" "${file}")
    c2=$(grep -c "^>>>>>>> " "${file}")
    if [[ c1 -gt 0 && c2 -gt 0 ]]; then
        echo "${fileShort} has a merge conflict"
    fi
done

Output

projectdir/file-name
projectdir/subdir/file-name

Split strings by line function

You can just copy the block of code if you don't want this as a separate function

function str_split_line(){
# for IFS, see https://stackoverflow.com/questions/16831429/when-setting-ifs-to-split-on-newlines-why-is-it-necessary-to-include-a-backspac
IFS="
"
    declare -n lines=$2
    while read line; do
        lines+=("${line}")
    done <<< "${1}"
}

Upvotes: 0

Costa
Costa

Reputation: 481

Utility git wizard https://github.com/makelinux/git-wizard counts separately unresolved conflicted changes (collisions) and unmerged files. Conflicts must be resolved manually or with mergetool. Resolved unmerged changes can me added and committed usually with git rebase --continue.

Upvotes: 0

Darrel Lee
Darrel Lee

Reputation: 2470

Here's what I use to a list modified files suitable for command line substitution in bash

git diff --numstat -b -w | grep ^[1-9] | cut -f 3

To edit the list use $(cmd) substitution.

vi $(git diff --numstat -b -w | grep ^[1-9] | cut -f 3)

Doesn't work if the file names have spaces. I tried to use sed to escape or quote the spaces and the output list looked right, but the $() substitution still did not behave as desired.

Upvotes: 0

cnlevy
cnlevy

Reputation: 11038

git diff --check

will show the list of files containing conflict markers including line numbers.

For example:

> git diff --check
index-localhost.html:85: leftover conflict marker
index-localhost.html:87: leftover conflict marker
index-localhost.html:89: leftover conflict marker
index.html:85: leftover conflict marker
index.html:87: leftover conflict marker
index.html:89: leftover conflict marker

source : https://ardalis.com/detect-git-conflict-markers

Upvotes: 204

Manu Artero
Manu Artero

Reputation: 10253

My 2 cents here (even when there are a lot of cool/working responses)

I created this alias in my .gitconfig

[alias]
 ...
 conflicts = !git diff --name-only --diff-filter=U | grep -oE '[^/ ]+$'

which is going to show me just the names of the files with conflicts... not their whole path :)

Upvotes: 1

Tzunghsing David Wong
Tzunghsing David Wong

Reputation: 1414

Assuming you know where your git root directory, ${GIT_ROOT}, is, you can do,

 cat ${GIT_ROOT}/.git/MERGE_MSG | sed '1,/Conflicts/d'

Upvotes: 2

sandesh
sandesh

Reputation: 1

As highlighted in other answer(s) we can simply use command git status and then look for files listed under Unmerged paths:

Upvotes: -3

Rafa
Rafa

Reputation: 1485

git status displays "both modified" next to files that have conflicts instead of "modified" or "new file", etc

Upvotes: 30

Eric
Eric

Reputation: 24890

This works for me:

git grep '<<<<<<< HEAD'

or

git grep '<<<<<<< HEAD' | less -N

Upvotes: 18

Emil Re&#241;a Enriquez
Emil Re&#241;a Enriquez

Reputation: 2971

you may hit git ls-files -u on your command line it lists down files with conflicts

Upvotes: 16

Patrick O&#39;Hara
Patrick O&#39;Hara

Reputation: 571

Maybe this has been added to Git, but the files that have yet to be resolved are listed in the status message (git status) like this:

#
# Unmerged paths:
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#   both modified:      syssw/target/libs/makefile
#

Note that this is the Unmerged paths section.

Upvotes: 3

taj
taj

Reputation: 701

slight variation of Charles Bailey's answer that gives more information:

git diff --name-only --diff-filter=U | xargs git status

Upvotes: 1

Ascherer
Ascherer

Reputation: 8093

I've always just used git status.

can add awk at the end to get just the file names

git status -s | grep ^U | awk '{print $2}'

Upvotes: 1

Jones Agyemang
Jones Agyemang

Reputation: 1516

Here is a fool-proof way:

grep -H -r "<<<<<<< HEAD" /path/to/project/dir

Upvotes: 55

inger
inger

Reputation: 20184

Trying to answer my question:

No, there doesn't seem to be any simpler way than the one in the question, out of box.

After typing that in too many times, just pasted the shorter one into an executable file named 'git-conflicts', made accessible to git, now I can just: git conflicts to get the list I wanted.

Update: as Richard suggests, you can set up an git alias, as alternative to the executable

git config --global alias.conflicts '!git ls-files -u | cut -f 2 | sort -u'

An advantage of using the executable over the alias is that you can share that script with team members (in a bin dir part of the repo).

Upvotes: 44

Tel
Tel

Reputation: 51

If you attempt to commit, and if there are conflicts, then git will give you the list of the currently unresolved conflicts... but not as a plain list. This is usually what you want when working interactively because the list gets shorter as you fix the conflicts.

Upvotes: 5

Related Questions