Re: [PATCH v6 4/4] reset: use "unpack_trees()" directly instead of "git read-tree"
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jan 1, 2010, 05:14 UTC
- Message-ID
- <7vtyv6o18q.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20091230055448.4475.64716.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
Show 17 quoted lines
> 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.
Show 10 quoted lines
> 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.