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

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Oct 19, 2010, 22:10 UTC
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 <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