On Thu, Nov 29, 2012 at 10:47 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Martin von Zweigbergk <martinvonz@xxxxxxxxx> 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.
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.
--
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