Re: [RFC/PATCH 1/2] reset: learn to reset to tree

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 29, 2012, 19:13 UTC
Message-ID: <7vzk20p6ik.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7v4nk8qmaj.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 12 quoted lines

> 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.

The above applies to an _arbitrary_ $sha1.

Allowing "reset $tree -- $pathspec" is a very good addition in the same sense that "git checkout $tree -- $pathspec" is useful. These two commands, "reset" and "checkout", share that the source we grab the blobs out of only need to be a tree and does not have to be a commit, and the only difference between them is where the blobs we grabbed out of that tree go, either only to the index or to both the index and the working tree.

But I do not think it is connected, at least at the level the end users perceive, to the issue of "reset" issued while on an unborn branch.

If you limit the scope of the behaviour change exposed to the end users so that you would make

	$ git reset [HEAD]

act as a short-hand for

	$ rm -f $GIT_DIR/index

when HEAD points at an unborn branch, and similarly make

	$ git reset --hard [HEAD]

act as a short-hand for

	$ rm -f $GIT_DIR/index
        $ git clean -f -d

in such a case, I do not think it is unreasonable at all.

In such a case,

	$ git reset --soft [HEAD]

would become just a no-op. Earlier you were on an unborn branch, and after "reset --soft", nothing changes.

Hmm?