Junio C Hamano <gitster@xxxxxxxxx> writes:
> 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.
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?
--
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