git reset --merge discrepancy with documentation

avenir 0
Viewed 68

Is it me or is the documentation for the --merge option of git reset formulated poorly or even incorrectly?

I cite the documentation:

Resets the index and updates the files in the working tree that are different between <commit> and HEAD, but keeps those which are different between the index and working tree (i.e. which have changes that have not been added). If a file that is different between <commit> and the index has unstaged changes, reset is aborted.

Not speaking about the fail condition of the command and speaking only of the first sentence. Does it mean that the files that don’t differ between <commit> and HEAD are not subject to the rollout of <commit> into the working directory?

I try the following script that doesn't change the file a between HEAD and HEAD~1:

#!/bin/bash
git init
echo 1 > a
echo 1 > b
git add .
git commit -m 1
echo 2 > b
git add .
git commit -m 2
echo 3 > a
echo 3 > b
git add .
git reset --merge HEAD~1
cat a
cat b
rm -rf .git

Why do the contents of the file a still get reset when they are supposed to stay unchanged?

git
1 Answers

The key here is the start of the description :

Resets the index,

Resetting the index means that it will become the same as the referred commit, with the specified exceptions. The index is the HEAD including staged files; as such resetting it will also remove any staged files.

Only files which are altered in your working tree and not staged will be kept. They must also not have changed between <commit> and the index, otherwise you get the fail condition.

I do agree the description is quite confusing, maybe it could be better.

Leonardo Dagnino0
Related