Re: [PATCH v6 0/4] "git reset --merge" related improvements

Linus Torvalds [off-list ref] writes:

On Wed, 30 Dec 2009, Christian Couder wrote:

quoted

Another reroll with the following changes:
- patches to add --keep option have been removed for now
- documentation patch has been moved before the core code changes
- commit messages have been improved
- tests have been much improved thanks to Junio's suggestions

Christian Couder (3):
  reset: improve mixed reset error message when in a bare repo
  Documentation: reset: add some tables to describe the different
    options
  reset: add a few tests for "git reset --merge"

Stephan Beyer (1):
  reset: use "unpack_trees()" directly instead of "git read-tree"

FWIW, Ack on this version of the whole series - I don't think there is 
anything controversial here, and I think avoiding the execve of read-tree 
for something we have a library function for is a good thing (and the 
change in behavior looks like a bug-fix to me).

The "bug-fix" needs my follow-up patch [*1*] to be a real "bug-fix", I
think.

By the way, I've always felt it somewhat confusing that "reset --merge"
implementation uses one-tree form of "read-tree -m -u", especially given
that your 9e8ecea (Add 'merge' mode to 'git reset', 2008-12-01) that
describes the "bug" contrasts its behaviour with the behaviour of going to
a different branch with "checkout", that is inherently an operation that
depends on the two-tree "read-tree -m -u" semantics.

In the context of "reset", however, we don't want the check "checkout"
does between the tree that the index came from (the first tree argument,
typically HEAD) and the index before going to the target tree (the second
tree argument), so it is the right thing to do to use the one-tree form
semantics "go from the state in the index to the target tree".


[Refererence]

*1* http://article.gmane.org/gmane.comp.version-control.git/136004