Martin von Zweigbergk [off-list ref] writes:
In cases where HEAD is not supposed to be updated, there is no reason
that "git reset" should require a commit, a tree should be enough. So
make "git reset $rev^{tree}" work just like "git reset $rev", except
that the former will not update HEAD (since there is no commit to
point it to).
That is a horrible design I have to nack, unless you require
pathspec. You cannot tell what "git reset $sha1" would do without
checking the type of the object $sha1 refers to. If you do this
only when pathspec is present, then the design is very reasonable.
Disallow --soft with trees, since that is about updating only HEAD.
Likewise.
On Thu, Nov 29, 2012 at 10:47 AM, Junio C Hamano [off-list ref] wrote:
Martin von Zweigbergk [off-list ref] writes:
quoted
In cases where HEAD is not supposed to be updated, there is no reason
that "git reset" should require a commit, a tree should be enough. So
make "git reset $rev^{tree}" work just like "git reset $rev", except
that the former will not update HEAD (since there is no commit to
point it to).
That is a horrible design I have to nack, unless you require
pathspec. You cannot tell what "git reset $sha1" would do without
checking the type of the object $sha1 refers to. If you do this
only when pathspec is present, then the design is very reasonable.
Very good point. Thanks! I now see that "git checkout" also requires a
path when given a tree.
So then "git reset" on an unborn branch would imply "git reset
$empty_tree -- ." instead. And "git reset --hard $tree" would not be
allowed. And the intersection of these -- "git reset --hard" on and
unborn branch -- would also not work. Would the correct fix be to
first make "git reset --hard -- $path" work (*sigh*)? I have never
understood why that doesn't (shouldn't) work.