983

I'm merging in a remote branch that may have a lot of conflicts. How can I tell if it will have conflicts or not?

I don't see anything like a --dry-run on git-merge.

Mahmoud Adam
  • 5,772
  • 5
  • 41
  • 62
Otto
  • 18,761
  • 15
  • 56
  • 62
  • 8
    This might help you: http://stackoverflow.com/questions/5817579/how-can-i-preview-a-merge-in-git – Coeffect Jun 13 '11 at 20:10
  • 1
    Explaining a bit more: I don't want to touch the working tree because I don't want to have it checked-out. That would take a long time if I want to see this information for several branches. – Penz Jun 14 '11 at 14:16
  • Oh - you mean you don't want to keep a local copy of the target branch? – Ian Robinson Jun 15 '11 at 16:26
  • 13
    Since branching is cheap with Git, why not checkout a copy and then you don't need to do a dry run? You can just throw out the copy afterward. – Alexander Mills Jul 14 '18 at 18:22
  • 3
    Good to know: since 06/01/20 there is a dry-run flag for pull (but still not for merge) – Codr Mar 19 '21 at 08:25

21 Answers21

1118

As noted previously, pass in the --no-commit flag, but to avoid a fast-forward commit, also pass in --no-ff, like so:

$ git merge --no-commit --no-ff $BRANCH

To examine the staged changes:

$ git diff --cached

And you can undo the merge, even if it is a fast-forward merge:

$ git merge --abort
Community
  • 1
  • 1
mipadi
  • 398,885
  • 90
  • 523
  • 479
  • 35
    Answer should mention that the exit status is `0` iff the merge is possible. – Ciro Santilli OurBigBook.com Jul 07 '14 at 14:30
  • 2
    cool! But how do I undo this operation? It says "all conflicts are fixed but you are still merging". Calling `git checkout .` doesn't revert the files to pre-merge status. – J-bob Dec 08 '14 at 16:38
  • 12
    NVM. Figured it out. You call `git merge --abort` – J-bob Dec 08 '14 at 16:42
  • Thanks a bunch. It really solved a very edge case issue I had with a feature to dev merge, that over-wrote a method body (that had no conflicts) back to an older version, because the feature branch had not been rebased (using Intellij idea, ultimate 2021.2 with git version 2.25.0 on windows). The merge option of Intellij does not have the above options as default...WITH THEM, the merge immediately flags the "silent" conflict. – Beezer Oct 27 '21 at 15:15
  • @J-bob `git reset --hard` also works. is there a difference to `git merge --abort` in this situation? – c8999c 3f964f64 Sep 09 '22 at 13:39
  • A little curious about the `git diff --cached` in the middle. Does that mean, git actually caches the result of first command. And not write to the file-system ? – Jaya Krishna Nov 04 '22 at 17:43
  • 1
    @JayaKrishna No, in preparation for a commit, Git "stages"/caches the changes that a subsequent commit will actually perform. `git diff --cached` (or `--staged`) displays only those changes. – Ti Strga Feb 09 '23 at 17:29
  • why do we need the `--no-ff` flag? – rredondo Mar 15 '23 at 09:32
  • 1
    @losaliens: A fast-forward merge is automatically committed. Since the intention was to examine the result of a merge without committing the merge, `--no-ff` was necessary to prevent it from being automatically committed. (It's not necessary in more recent versions of Git.) – mipadi Mar 16 '23 at 01:40
287

I just had to implement a method that automatically finds conflicts between a repository and its remote. This solution does the merge in memory so it won't touch the index, nor the working tree. I think this is the safest possible way you can solve this problem. Here's how it works:

  1. Fetch the remote to your repository. For example: git fetch origin master
  2. Run git merge-base: git merge-base FETCH_HEAD master
  3. Run git merge-tree: git merge-tree mergebase master FETCH_HEAD (mergebase is the hexadecimal id that merge-base printed in the previous step)

Now suppose that you want to merge the remote master with your local master, but you can use any branches. git merge-tree will execute the merge in memory and print the result to the standard output. Grep for the pattern << or >>. Or you can print the output to a file and check that. If you find a line starting with 'changed in both' then most probably there will be a conflict.

Trevor Hickey
  • 36,288
  • 32
  • 162
  • 271
akostajti
  • 2,997
  • 1
  • 14
  • 6
  • 29
    BTW, steps 2 and 3 can be merged into one step, using the backtick operator of Linux console, which evaluates in-place its contents: `git merge-tree \`git merge-base FETCH_HEAD master\` FETCH_HEAD master` – jakub.g Aug 08 '12 at 14:53
  • 22
    Add to [alias] in .gitconfig: dry = "!f() { git merge-tree \`git merge-base $2 $1\` $2 $1; }; f" #check how the merge of dev into master will go: git dry dev master – Noel Dec 17 '12 at 20:51
  • 1
    My tests with this method are showing false-positives (actual merge went well, yet merge-tree output contains "changed in both"). Here's the alias I'm using: dry = "!f() { grep -q 'changed in both' <<< $(git merge-tree $(git merge-base FETCH_HEAD $1) $1 FETCH_HEAD) && echo 'Merge conflict detected' || echo 'Merged cleanly'; }; f" – jasond May 09 '13 at 14:42
  • 12
    My new fav GIT line: ``git merge-tree `git merge-base clieop master` clieop master | grep -A3 "changed in both"`` Simply awesome! +100 – Rudie Aug 09 '13 at 20:38
  • 8
    In testing this I found grepping for 'changed in both' flags merges where both branches modify the same file, even if they do not result in a merge conflict. To identify only actual conflicts I found it necessary to grep for the conflict markup that starts like this: `+<<<<<<< .our`, so I use a grep expression like `grep -q '^+<* \.our$'` – Guy Mar 05 '14 at 00:14
  • 2
    Nice! Here is my current favorite: `git merge-tree $(git merge-base $1 $2) $1 $2 | sed -n '/+<<<<<<< .our/,/+>>>>>>> .their/p;/^changed in both/{n;N;N;s/^/#/mg;p}' | cdiff`. It extracts the "changed in both" lines as well as the conflicting parts. – MvG Mar 27 '14 at 15:03
  • I have no idea if I have changed the behavior or not, but with these POSIX compliant changes (including removal of `m` flag to `s`) I have it running on macOS: `sed -n -e '/+<<<<<<< .our/,/+>>>>>>> .their/p' -e '/^changed in both/ {' -e 'n' -e 'N' -e 'N' -e 's/^/#/g' -e 'p' -e '}'` – Steven Lu Jan 02 '18 at 03:48
  • @StevenLu: The line "changed in both" is followed by three lines: base, our and their, each with mode, id hash and path. `n;N;N` collects these three lines in the buffer. The `m` modifier to `s///` uses multi-line mode so the `^` will match all three line beginnings, thus adding `#` to all of them. Without `m` you get a `#` for the first line but not the others. You could do three separate `n;s/^/#/;p`, one for each line. Or you could decide to omit those comment characters and drop the whole `s/^/#/`. Dropping the `m` only feels inconsistent. – MvG Jan 02 '18 at 10:28
  • @StevenLu: The GNU sed manual would be the canonical place: https://www.gnu.org/software/sed/manual/sed.html#The-_0022s_0022-Command – MvG Jan 02 '18 at 21:40
  • are master and FETCH_HEAD swapped in step 3? – dfreese Apr 09 '19 at 04:55
  • 2
    This answer is almost good. Unfortunately it doesn't work in case of conflicts where one branch changed one file while the other branch deleted that same file. – Thiago Barcala Jun 06 '19 at 17:18
  • 2
    IMNSHO, this functionality should be **upstreamed** under a new 'git merge --dry-run' flag. – qneill Jan 30 '20 at 20:17
  • @ThiagoBarcala Those conflicts will be 'removed in remote' and have different shas for `base` and `our` – kuceb May 20 '20 at 22:49
116

I'm assuming you just want to find out how much trouble you're getting yourself into prior to actually attempting the merge...and resetting to the last commit after a failed merge is relatively easy so I wouldn't be surprised if that is the intended approach.

That said, if you really don't want to touch your existing files in the working tree - you could create a patch and test it against the target branch. This also has the benefit of showing exactly what changes were made to which files - just open up the patch file in a text editor.

git checkout -b mycrazybranch
[change some stuff...]
git add .
git commit -m "changed some stuff"
git format-patch master --stdout > crazy.patch
git checkout master
git apply crazy.patch --check
[all good! cleanup...]
rm crazy.patch

As you can see, this will create a patch file, you can then test it with --check and see if there are any errors, then remove the patch file.

Ian Robinson
  • 16,892
  • 8
  • 47
  • 61
  • 56
    It worked! You don't even need a temporary file if you do: `git format-patch master --stdout | git-apply --check -` – Penz Jun 15 '11 at 16:50
  • 6
    @Penz In my git v1.8.1.1 `git-apply` won't work. It must read `git apply`. – yunzen Feb 28 '13 at 09:46
  • 13
    This wasn't accurate for me - git wasn't able to use the 'recursive' merge strategy when applying the patch, so it had conflicts, but it worked fine with a 'git merge'. – rescdsk Dec 17 '14 at 15:28
  • 4
    Another problem, patch file gives error for new files created within new branch. – Tahsin Turkoz Feb 10 '17 at 18:50
83

You can do git merge --abort after seeing that there are conflicts.

manojlds
  • 290,304
  • 63
  • 469
  • 417
  • 41
    Right, but that doesn't work if you want to not apply it even if there's not conflicts. As in literally just _check_. – OJFord Aug 08 '16 at 07:06
  • 4
    @OllieFord How about using it with --no-commit --no-ff options? – Samuel Robert Dec 31 '16 at 07:16
  • 22
    @SamuelRobert In other words: `git merge other-branch --no-commit --no-ff; git merge --abort` - seems to work pretty well. – seanf Oct 09 '17 at 02:56
  • How do I see the changes that the merge would have made to my current branch/working tree? – PatS Apr 13 '23 at 12:00
74

As a summary of existed answers, there are two way to check if there would be merge conflicts

git format-patch $(git merge-base branch1 branch2)..branch2 --stdout | git apply --3way --check -

Note, your current branch should be branch1 when you run above command

Another way:

git merge --no-commit branch2
# check the return code here
git merge --abort
Will Beason
  • 3,417
  • 2
  • 28
  • 46
Congbin Guo
  • 1,685
  • 2
  • 16
  • 16
64

My simple brute-force solution to this is:

  1. Create a "pre-master" branch (from master of course)

  2. Merge all the things you want to into this pre-master.
    Then you can see how the merging happened without touching master.

    • Merge pre-master into master OR
    • Merge all wannabe-released branches into master

Anyway, I would follow @orange80's advice.

Michael
  • 8,362
  • 6
  • 61
  • 88
hades
  • 657
  • 5
  • 2
  • 8
    I like @akostajti solution, but this is yet another underrated option. In fact I prefer to be defensive and create a new temp branch (of course only when I expect conflicts, otherwise it'll be an overkill), and if something goes wrong, simply delete it. – jakub.g Aug 03 '12 at 21:47
  • 2
    dunno if this is a "dirty" solution or not, but it really does the job. I like it! (Y) – sara Oct 07 '15 at 14:17
  • 4
    This should be the accepted solution, imo. It's quick, easy, safe, reversible, intuitive, and as long as there are no uncommited changes before you start, it will have no side effects. – Bob Ray Jun 08 '18 at 20:00
  • 4
    This solution tells you do not understand how git works. Branch are just pointers and you are only creating a redundant pointer. You have a bad feeling that you can somehow hurt your branch merging but you cannot. You can always do `git merge --abort` if there are conflicts, `git reset --hard HEAD~1` if there was a merge or `git reset --hard origin/master`. Creating another branch gives you a feeling of safety but if you learn how git works you will understand it is misplaced fear. When concern is about not changing the working copy, this offers no solution. – Thibault D. Jan 29 '19 at 07:35
  • 2
    @thibault-d Think about how complex the solution is when you don't start with a clean branch. `git merge --no-commit` won't abort a merge if it can be fast forwarded. `git merge --abort` doesn't work if it was merged. If you want to write this as a script, it's awkward, since `git merge` doesn't reply with good enough error codes to explain the different types of conflicts. Working with a fresh branch prevents a broken script from leaving your repo in a state that requires manual intervention. Sure you can't lose anything. But it's easier to build otherwise. – Erik Aronesty Oct 17 '19 at 12:39
  • **Note:** Another caveat to using this approach: if your pre-master branch has conflicts, and you want to delete it completely, you will not be able to delete it without switching to another branch. However, git will throw an error if you try to switch to another branch while you have uncommitted changes. The workaround for this is to use the `-f` flag. **See also:** https://stackoverflow.com/a/44077579/42223 – dreftymac Nov 04 '19 at 06:38
  • 1
    @dreftymac Can you not just git merge --abort before checking out another branch? – Robert Taussig Mar 31 '21 at 14:03
56

I made an alias for doing this and works like a charm, I do this:

 git config --global alias.mergetest '!f(){ git merge --no-commit --no-ff "$1"; git merge --abort; echo "Merge aborted"; };f '

Now I just call

git mergetest <branchname>

To find out if there are any conflicts.

Okonomiyaki3000
  • 3,628
  • 23
  • 23
48

Undoing a merge with git is so easy you shouldn't even worry about the dry run:

$ git pull $REMOTE $BRANCH
# uh oh, that wasn't right
$ git reset --hard ORIG_HEAD
# all is right with the world

EDIT: As noted in the comments below, if you have changes in your working directory or staging area you'll probably want to stash them before doing the above (otherwise they will disappear following the git reset above)

Brian Phillips
  • 12,693
  • 3
  • 29
  • 26
  • True, but in this case I had done the complex merge in a branch off master and wanted to be 100% sure it was a good FF merge. Had it not been I'd have gone back to the other branch and done something similar to your answer to get it in shape. – Otto Feb 01 '09 at 22:09
  • 8
    Simply checking if a merge will be fast-forward (FF) is a matter of checking the list of `git branch --contains HEAD` or even more directly, just use `git merge --ff-only` – Brian Phillips Dec 06 '10 at 19:39
  • 9
    git reset --hard is one of the few deletion-of-information-with-no-backout commands that git has, so should be used with extreme caution. As such, -1 – Kzqai Feb 22 '12 at 21:40
  • 10
    @Tchalvak there is still reflog. – Kissaki May 17 '12 at 13:35
  • @BrianPhillips hadn't noticed the --contains flag for git branch before. +1 for pointing it out, as it's a nice converse of --merged that I've been lacking for a while. – Daniel Kessler Jul 25 '12 at 17:58
  • 4
    `--dry-run` wouldn't "simply check if a merge will be fast-forward". It would return the exact output that a merge would: files, conflicts etc. Whether is will ff isn't really interesting, is it? – Rudie Dec 22 '12 at 19:04
  • @Rudie - the OP mentioned in his comment (from Feb 1, '09) that he was wanting to ensure the merge would be a fast-forward merge. – Brian Phillips Dec 23 '12 at 17:11
  • Not the best advise when working on large production environments (and saying "you should be using a development environment", while correct, doesn't help lowly plebian programmers working for "the man" who says "just do it live") – Nathan Crause Apr 18 '13 at 19:26
  • 1
    `git reset --hard` can destroy staged changes – Code Whisperer Jan 14 '15 at 18:14
  • @itcouldevenbeaboat - how else would you suggest the OP undo the merge as described in the original question? – Brian Phillips Jan 15 '15 at 20:08
  • 4
    how about `git stash; git reset --hard` ? @BrianPhillips – Code Whisperer Jan 15 '15 at 20:12
  • 2
    `git reset` would ditch any local uncommitted changes. This is dangerous and should be last resort. – Sheng Dec 11 '15 at 16:42
  • This may indeed be "easy", but if you forget (just this once!) to stash first, it's dangerous. It's easier to user power tools without the guards in place too -- and pretty safe so long as you never, ever slip up. – TextGeek Aug 23 '21 at 14:51
27

Just diff your current branch against the remote branch, this will tell you what is going to change when you do a pull/merge.

#see diff between current master and remote branch
git diff master origin/master
timh
  • 1,572
  • 2
  • 15
  • 25
  • 2
    Interesting idea. How would I look at that output and determine whether the merge is going to work or not? – Tyler Jan 25 '11 at 03:19
  • 10
    This wont tell you if any conflicts will occur... but it'll give you a general idea of what will take place if you did a pull/merge. – timh Feb 21 '11 at 09:08
  • 16
    This will only tell you the difference between the two branches, it won't tell you what the result of the merge will be. This is an important distinction as merging will in some cases automatically take changes from different branches depending on when they were committed. So in essence, doing a diff might make you think some of your changes will be reverted when in actuality, the merge process will automatically take newer changes over older ones. Hope that makes sense. – markquezada Oct 02 '11 at 01:39
  • 4
    To build on @mirthlab's comment, there will be a significant difference between diff and merge if someone previously performed a merge with the "ours" merge strategy (or some other manual merge fixups); the diff will also show you differences that are already counted as "merged". – Tao May 07 '12 at 14:13
26

I'm surprised nobody has suggested using patches yet.

Say you'd like to test a merge from your_branch into master (I'm assuming you have master checked out):

$ git diff master your_branch > your_branch.patch
$ git apply --check your_branch.patch
$ rm your_branch.patch

That should do the trick.

If you get errors like

error: patch failed: test.txt:1
error: test.txt: patch does not apply

that means that the patch wasn't successful and a merge would produce conflicts. No output means the patch is clean and you'd be able to easily merge the branch


Note that this will not actually change your working tree (aside from creating the patch file of course, but you can safely delete that afterwards). From the git-apply documentation:

--check
    Instead of applying the patch, see if the patch is applicable to the
    current working tree and/or the index file and detects errors. Turns
    off "apply".

Note to anyone who is smarter/more experienced with git than me: please do let me know if I'm wrong here and this method does show different behaviour than a regular merge. It seems strange that in the 8+ years that this question has existed noone would suggest this seemingly obvious solution.

  • 2
    This method is the accepted answer [for this question](https://stackoverflow.com/questions/6335717/can-git-tell-me-if-a-merge-will-conflict-without-actually-merging) and there are some caveats in the comments such as "git wasn't able to use the 'recursive' merge strategy" and "patch file gives error for new files". Otherwise, seems great. – neno Oct 27 '17 at 15:34
  • 5
    A shorter way without creating a temporary patch file: `git diff master your_branch | git apply --check`. – ks1322 Apr 20 '18 at 10:32
24

Not exactly like that. But you can use the --no-commit option, so it does not automatically commit the result after the merge. In this way you can inspect, and if desired, to undo the merge without messing with the commit tree.

Alexandre
  • 1,016
  • 3
  • 13
  • 23
23

I use the request-pull git command to do so. It allows you to see every change that would happen when merging, but without doing anything on your local or remote repositories.

For instance, imagine you want to merge a branch named "feature-x" into your master branch

git request-pull master origin feature-x

will show you a summary of what would happen (without doing anything):

The following changes since commit fc01dde318:
    Layout updates (2015-06-25 11:00:47 +0200)
are available in the git repository at:
    http://fakeurl.com/myrepo.git/ feature-x
for you to fetch changes up to 841d3b41ad:
----------------------------------------------------------------
john (2):
    Adding some layout
    Refactoring
ioserver.js            |   8 +++---
package.json           |   7 +++++-
server.js              |   4 +--
layout/ldkdsd.js       | 277 +++++++++++++++++++++++++++++++++++++
4 files changed, 289 insertions(+), 7 deletions(-)
create mode 100644 layout/ldkdsd.js

If you add the -pparameter, you will also get the full patch text, exactly like if you were doing a git diff on every changed file.

ArnaudR
  • 1,954
  • 18
  • 19
  • 3
    You could make this a bit clearer by adding what `master` and `origin` do in the command-line options, and what about if I am for example on a local `branch1` and want to do a `request-pull` on a local feature branch `branch2`? Do I still need `origin`? Of course, one can always read the documentation. – Ela782 Jul 23 '15 at 13:19
  • Sadly this command only works if Rev#2 is a branch name, it doesn't work for hashes :/ – Jared Grubb Aug 29 '18 at 20:43
14

Git introduced a --ff-only option when merging.

From: http://git-scm.com/docs/git-merge


--ff-only

Refuse to merge and exit with a non-zero status unless the current HEAD is already up-to-date or the merge can be resolved as a fast-forward.

Doing this will attempt to merge and fast-forward, and if it can't it aborts and prompts you that the fast-forward could not be performed, but leaves your working branch untouched. If it can fast-forward, then it will perform the merge on your working branch. This option is also available on git pull. Thus, you could do the following:

git pull --ff-only origin branchA #See if you can pull down and merge branchA

git merge --ff-only branchA branchB #See if you can merge branchA into branchB
pkamb
  • 33,281
  • 23
  • 160
  • 191
Jason McKindly
  • 463
  • 1
  • 8
  • 15
  • 2
    That will do the merge if it can be done with fast forward which is not what I wanted in the original question. I think the accepted answer has the other half that fixes it. – Otto Jun 11 '15 at 20:19
  • Really though, fancy git prompts obviate the need I have for this sort of thing. – Otto Jun 11 '15 at 20:19
  • 5
    It's not really the same. Exiting with non-zero status because merge can't be resolved as fast-forward **doesn't mean there are conflicts**. It just means the history has diverged and a merge commit is necessary. – ADTC Nov 28 '17 at 16:24
9

This might be interesting: From the documentation:

If you tried a merge which resulted in complex conflicts and want to start over, you can recover with git merge --abort.

But you could also do it the naive (but slow) way:

rm -Rf /tmp/repository
cp -r repository /tmp/
cd /tmp/repository
git merge ...
...if successful, do the real merge. :)

(Note: It won't work just cloning to /tmp, you'd need a copy, in order to be sure that uncommitted changes will not conflict).

  • 2
    If all you need is a hammer... :) +1 – kaiser Aug 18 '14 at 00:07
  • Clean copy can be obtained with `cp -r repository/.git /tmp/repository/.git`, `cd /tmp/repository`, `git reset --hard`, `git add --all`, `git reset --hard` (for good measure), `git status` (to check that it's clean). – ADTC Nov 28 '17 at 16:21
8

I use git log to see what has changed on a feature branch from master branch

git log does_this_branch..contain_this_branch_changes

e.g. - to see what commits are in a feature branch that has/not been merged to master:

git log master..feature_branch
nelsonenzo
  • 682
  • 5
  • 9
8

My solution is to merge backwards.

Instead of merging your branch into the remote "target" branch, merge that branch into yours.

git checkout my-branch
git merge origin/target-branch

You will see if there are any conflicts and can plan on how to solve them.

After that you can either abort the merge via git merge --abort, or (if there weren't any conflicts and merge has happened) roll back to previous commit via git reset --hard HEAD~1

Ubeogesh
  • 1,633
  • 2
  • 15
  • 22
6

I want to see just the conflicts (can't see them with diff3 in GitHub, yet). Leveraging heavily from this answer above, I came up with this:

git merge --no-commit --no-ff @{upstream}
git grep -l '<<<<<<< HEAD' | xargs -I % sh -c "echo -e '\n\e[93m%\n---\e[0m' && cat %"
git merge --abort

For me, this is for checking my PRs. You can substitute @{upstream} with whatever branch.

I hope that's helpful to someone.

Jim Ivey
  • 93
  • 1
  • 5
2

If you want to fast forward from B to A, then you must make sure that git log B..A shows you nothing, i.e. A has nothing that B doesn't have. But even if B..A has something, you might still be able to merge without conflicts, so the above shows two things: that there will be a fast-forward, and thus you won't get a conflict.

Erik Kaplun
  • 37,128
  • 15
  • 99
  • 111
1

I know this is theoretically off-topic, but practically very on-topic for people landing here from a Google search.

When in doubt, you can always use the Github interface to create a pull-request and check if it indicates a clean merge is possible.

Mentor
  • 965
  • 9
  • 21
  • 7
    If you use GitHub, GitLab or something similar this can be of use. But that's not always the case. Knowing your way on the command line is the real power. – cezar Feb 23 '21 at 07:46
  • 1
    I agree, just adding if for the less cli inclined that are having a bad day and landing here from Google. – Mentor Feb 24 '21 at 08:18
0

Another option would be to do a "virtual" merge and easily see the result of the merge, including conflicts:

# Define the branches
origin_branch="$(git rev-parse --abbrev-ref HEAD)" #get current checked out branch
destination_branch="origin/main"

# Perform the merge-tree command (virtual merge)
git merge-tree --write-tree $origin_branch $destination_branch

And if you want to see only the conflicts, you can modify the script above as follows:

# Define the branches
origin_branch="$(git rev-parse --abbrev-ref HEAD)" #get current checked out branch
destination_branch="origin/main"

# Perform the merge-tree command and capture the output
merge_output=$(git merge-tree --write-tree --name-only $origin_branch $destination_branch)

# Extract file names with conflicts from the merge output using grep and store in an array
mapfile -t conflicted_files < <(echo "$merge_output" | grep -E '^CONFLICT*' | awk '{print $NF}')

# Display the list of file conflicts
echo "Conflicts found in the following files:"
printf '%s\n' "${conflicted_files[@]}"
Eyal Gerber
  • 1,026
  • 10
  • 27
-2

Make a temporary copy of your working copy, then merge into that, and diff the two.

vanboom
  • 1,274
  • 12
  • 20