Christian Couder <chriscool@xxxxxxxxxxxxx> 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.
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html