From: Martin von Zweigbergk <martinvonz@gmail.com>
Date: Thu, 29 Nov 2012 19:04:30 GMT
Subject: Re: [RFC/PATCH 1/2] reset: learn to reset to tree
Message-ID: <CANiSa6j2sriXaGr0yH9kMrxDEvKHsjNPX_Exbc2_6ecnPYdroQ@mail.gmail.com>
In-Reply-To: <7v4nk8qmaj.fsf@alter.siamese.dyndns.org>

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