From: Jonathan Nieder Date: Tue, 19 Oct 2010 22:10:05 GMT Subject: [RFC/PATCH 0/4] reset: be more flexible about Message-ID: <20101019221005.GC32029@burratino> In-Reply-To: <7vhbgiyoo9.fsf@alter.siamese.dyndns.org> Junio C Hamano wrote: > It is probably Ok to limit the scope of this change to the case without > any explicit rev, e.g. "git reset -- frotz.c", but at that point I somehow > don't think it will reduce confusion but rather will make things worse. I wouldn't be surprised to find people using git reset HEAD just because '--' did not come to mind quickly enough. For example, I have a faint memory of doing that myself a couple of years ago. Why should Git mind? Patch 1 below teaches reset -p to accept an arbitrary tree for . Unfortunately add--interactive notices but does not error out when is a blob; that should be fixed in the add--interactive script by checking the exit status of commands it runs, I think (help from those more comfortable in perl would be appreciated). Patch 2 removes the arbitrary restriction in "git reset " that be a commit. It also paves the way for writing patch 3 more clearly. Patch 3 is the "probably Ok" change you mentioned above. It allows use of "git reset" to un-add a file from an unborn branch. Patch 4 is like patch 3, but for "git reset HEAD". Help on finishing up patch 1 (or comments to the effect that it is pointless) would be welcome. Jonathan Nieder (4): reset -p: accept "git reset -p " reset: accept "git reset " reset: accept "git reset -- " from unborn branch reset: accept "git reset HEAD " from unborn branch builtin/reset.c | 27 ++++++++++++++++------- t/t7102-reset.sh | 31 +++++++++++++++++++++++++++ t/t7105-reset-patch.sh | 12 ++++++++++ t/t7106-reset-unborn.sh | 53 +++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 115 insertions(+), 8 deletions(-) create mode 100755 t/t7106-reset-unborn.sh -- 1.7.2.3