tags:

views:

1069

answers:

2

In my experiments I haven't been able to find any functional difference between

git reset --hard

and

git reset --merge

The usage instructions don't give any hint either

--hard                reset HEAD, index and working tree
--merge               reset HEAD, index and working tree

I regularly use the --hard option so understand how that works. What's the difference between the --merge and the --hard options?

Cheers, Olly

Perhaps an example would help here, let's use the following sequence:

cd git_repo
touch file_one
git add file_one
git commit -m "commit one" # sha1 of 123abc
echo "one" >> ./file_one
git commit -a -m "commit two" # sha1 of 234bcd
echo "two" >> ./file_one
git add . # populate index with a change
echo "three" >> ./file_one # populate working area with a change

Now if I try

git reset --merge 123abc

I get

error: Entry 'file_one' not uptodate. Cannot merge.
fatal: Could not reset index file to revision '123abc'

the reason being that file_one has changes in both the working area and the index

To remedy this I do

git add .
git reset --merge 123abc

This time it works, however, I get the same result as git reset --hard. The index is empty, working area is empty, file_one is empty, as it was after first commit.

Can someone come up with the steps that illustrate the difference?

A: 

Apparently according to:

http://www.kernel.org/pub/software/scm/git/docs/git-reset.html

--hard - Matches the working tree and index to that of the tree being switched to. Any changes to tracked files in the working tree since are lost.

--merge - Resets the index to match the tree recorded by the named commit, and updates the files that are different between the named commit and the current commit in the working tree.

Jon
+5  A: 

From git reset manpage:

--hard    Matches the working tree and index to that of the tree being
               switched  to. Any changes to tracked files in the working tree since
               <commit> are lost.

--merge
              Resets the index to match the tree recorded by the named commit, and
              updates the files that are different between the named commit and
              the current commit in the working tree.

The git reset --merge is meant to be a safer version of git reset --hard, when your changes and somebody else changes are mixed together, trying to carry our changes around.

Jakub Narębski
I have read those docs, but have to say I can't make much sense of them. "Resets the index to match the tree recorded by the named commit"My understanding is that the index is empty after the reset --merge operation, this comment seems to indicate something else."and updates the files that are different between the named commit and the current commit in the working tree"where are the updates that are made to these files, they don't appear in the index, are they committed automatically?
opsb
After `git reset --merge <commit>` you have index == <commit>, but it updates only those files in working are that are different between HEAD (current commit) and <commit> (named commit), preserving (some of) your local changes.
Jakub Narębski
In the example I have above I found that I couldn't perform a git reset --merge when I had changes in the working area. Is this in fact possible using different steps from those that I've shown above?
opsb
Ok, so the issue was that I had the same file in both the index and the working area. With different files I see the behaviour that you describe.
opsb
So it appears that the difference between --hard and --merge is that files with changes in the working area are kept if possible. It isn't possible for files that have changed since the version that you are resetting to. In this case they are simply reset to the old version with any changes being discarded.
opsb