Is there a git-merge --dry-run option?

Question

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.

Avruch

This might help you: #5818079 – Ailbert

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. – Secede

Oh - you mean you don't want to keep a local copy of the target branch? – Dardar

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. – Gilliette

Good to know: since 06/01/20 there is a dry-run flag for pull (but still not for merge) – Warnerwarning

Answer 1

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

Lampedusa

Answer should mention that the exit status is 0 iff the merge is possible. – Dotty

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. – Absolutely

NVM. Figured it out. You call git merge --abort – Absolutely

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. – Arnuad

@Absolutely git reset --hard also works. is there a difference to git merge --abort in this situation? – Chafer

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 ? – Chelate

@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. – Ghiberti

why do we need the --no-ff flag? – Nyeman

@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.) – Lampedusa

Answer 2

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.

Gilbye

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 – Kristikristian

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 – Giffer

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" – Krissie

My new fav GIT line: git merge-tree `git merge-base clieop master` clieop master | grep -A3 "changed in both" Simply awesome! +100 – Synchroscope

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$' – Bethannbethanne

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. – Deliciadelicious

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 '}' – Chalcanthite

@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. – Deliciadelicious

@StevenLu: The GNU sed manual would be the canonical place: gnu.org/software/sed/manual/sed.html#The-_0022s_0022-Command – Deliciadelicious

are master and FETCH_HEAD swapped in step 3? – Stemware

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. – Destroy

IMNSHO, this functionality should be upstreamed under a new 'git merge --dry-run' flag. – Splenius

@ThiagoBarcala Those conflicts will be 'removed in remote' and have different shas for base and our – Electrobiology

With git 2.40 or newer you can use the --merge-base option which makes the output contain the extra conflict info, e.g.: git merge-tree --merge-base $(git merge-base A B) A B will give you an output like this: CONFLICT (modify/delete): FILE deleted in A and modified in B. Version B of FILE left in tree. – Allover

Answer 3

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.

Dardar

It worked! You don't even need a temporary file if you do: git format-patch master --stdout | git-apply --check - – Secede

@Secede In my git v1.8.1.1 git-apply won't work. It must read git apply. – Melanymelaphyre

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'. – Zhukov

Another problem, patch file gives error for new files created within new branch. – Filthy

Answer 4

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

Relativize

Right, but that doesn't work if you want to not apply it even if there's not conflicts. As in literally just check. – Emalia

@OllieFord How about using it with --no-commit --no-ff options? – Jenjena

@SamuelRobert In other words: git merge other-branch --no-commit --no-ff; git merge --abort - seems to work pretty well. – Imago

How do I see the changes that the merge would have made to my current branch/working tree? – Vo

Answer 5

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

Mice

If you replace branch1 with HEAD, your command works from any branch. – Peso

Actually, your first command does not do a proper 3-way merge, so you'll get a bunch of false positives. The second way works much better. – Peso

@MarkLodato I prefer the second as well, but you could provide --3way to git apply. – Ssr

Answer 6

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.

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

Anyway, I would follow @orange80's advice.

Hauler

I like @Gilbye 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. – Kristikristian

dunno if this is a "dirty" solution or not, but it really does the job. I like it! (Y) – Rowdyish

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. – Dedra

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. – Caryophyllaceous

@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. – Bloodthirsty

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://mcmap.net/q/48073/-why-can-i-not-switch-branches – Limit

@Limit Can you not just git merge --abort before checking out another branch? – Vision

Answer 7

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.

Seanseana

Answer 8

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)

Thunderbolt

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. – Avruch

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 – Thunderbolt

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 – Riddance

@Tchalvak there is still reflog. – Inhabited

@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. – Thao

--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? – Synchroscope

@Synchroscope - the OP mentioned in his comment (from Feb 1, '09) that he was wanting to ensure the merge would be a fast-forward merge. – Thunderbolt

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") – Biostatics

git reset --hard can destroy staged changes – Norway

@itcouldevenbeaboat - how else would you suggest the OP undo the merge as described in the original question? – Thunderbolt

how about git stash; git reset --hard ? @BrianPhillips – Norway

git reset would ditch any local uncommitted changes. This is dangerous and should be last resort. – Astigmatic

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. – Hummocky

Answer 9

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

Karolekarolina

Interesting idea. How would I look at that output and determine whether the merge is going to work or not? – Choreography

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. – Karolekarolina

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. – Counterirritant

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". – Alleviate

Answer 10

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.

Algophobia

This method is the accepted answer for this question 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. – Selfcentered

A shorter way without creating a temporary patch file: git diff master your_branch | git apply --check. – Callas

Answer 11

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.

Ouidaouija

Answer 12

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.

Nagari

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. – Mating

Sadly this command only works if Rev#2 is a branch name, it doesn't work for hashes :/ – Aceldama

Answer 13

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

Marginate

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. – Avruch

Really though, fancy git prompts obviate the need I have for this sort of thing. – Avruch

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. – Devastating

Answer 14

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).

Spanner

If all you need is a hammer... :) +1 – Outmoded

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). – Devastating

Answer 15

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

Logo

Answer 16

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

Orthogenetic

Answer 17

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.

Scifi

Answer 18

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.

Measure

Answer 19

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.

Bennett

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. – Hildebrand

I agree, just adding if for the less cli inclined that are having a bad day and landing here from Google. – Bennett

Answer 20

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[@]}"

Mediatize

Answer 21

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

Flask

this solution requires lots of work and so much time... there are plenty another better solutions – Chapter