Re: [PATCH v6 4/4] reset: use "unpack_trees()" directly instead of "git read-tree"
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:47:57
Christian Couder [off-list ref] writes:
But in 9e8ecea (Add 'merge' mode to 'git reset', 2008-12-01) there is
the following:
"
- if the index has unmerged entries, "--merge" will currently
simply refuse to reset ("you need to resolve your current index
first"). You'll need to use "--hard" or similar in this case.
This is sad, because normally a unmerged index means that the
working tree file should have matched the source tree, so the
correct action is likely to make --merge reset such a path to
the target (like --hard), regardless of dirty state in-tree or
in-index. But that's not how read-tree has ever worked, so..
"
So the new behavior looks better according to the original
implementation of "git reset --merge".This is not really an improvement.. You are swapping an breakage with a different breakage of a riskier kind. At least disallowing means that the user _is notified_ and has to manually deal with the situation. Pretending it succeeded by resetting only the index while still leaving the conflicted state in the work tree intact is a bit worse in that sense.
quoted hunk
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt index c9044c9..b40999f 100644 --- a/Documentation/git-reset.txt +++ b/Documentation/git-reset.txt@@ -122,7 +122,7 @@ entries: X U A B --soft (disallowed) --mixed X B B --hard B B B - --merge (disallowed) + --merge X B B
IOW, I think the result should be "B B B" instead of "X B B" in this case.