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 <paths> 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 <rev>. Unfortunately add--interactive notices but does not error out when <rev> 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 <rev> <path>" that <rev> 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 <tree>" reset: accept "git reset <tree> <path>" reset: accept "git reset -- <path>" from unborn branch reset: accept "git reset HEAD <path>" 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 -- 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