[RFC/PATCH 0/4] reset: be more flexible about <rev>

[Jonathan Nieder <jrnieder@gmail.com>]

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