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.
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:
git fetch origin mastergit merge-base FETCH_HEAD mastergit 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.
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
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.
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.
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
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.
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
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)
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.
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
My simple brute-force solution to this is:
Create a "pre-master" branch (from master of course)
Merge all the things you want to into this pre-master.
Then you can see how the merging happened without touching master.
Anyway, I would follow @orange80's advice.
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.
You can do git merge --abort after seeing that there are conflicts.
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.
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).
Make a temporary copy of your working copy, then merge into that, and diff the two.
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
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
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).
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.
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)
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.
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.
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.
Make a temporary copy of your working copy, then merge into that, and diff the two.
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.
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)
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.
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.
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
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
My simple brute-force solution to this is:
Create a "pre-master" branch (from master of course)
Merge all the things you want to into this pre-master.
Then you can see how the merging happened without touching master.
Anyway, I would follow @orange80's advice.
You can do git merge --abort after seeing that there are conflicts.
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
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:
git fetch origin mastergit merge-base FETCH_HEAD mastergit 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.
Source: Stackoverflow.com