Re: [PATCH] Introduce "reset type" flag to "git reset"

[Yasushi SHOJI <yashi@atmark-techno.com>]

At Tue, 23 Aug 2005 15:08:44 -0700,
Junio C Hamano wrote:
> 
> Sam Ravnborg <sam@ravnborg.org> writes:
> 
> > But --soft, --hard looks rather confusing to me.
> >
> > Something like --force or --prune may be a bit more intuitive, and let
> > default behaviour be the one you name --soft for now.
> 
> I do not have objections to removing --mixed, but I do not find
> --force/--prune any less confusing than --soft/--hard.  Its just
> a terminology so once people get used to it anything would do.
> But I agree that we need to come up with a good name for them.
> I do not think --force/--prune is it, though.

I think the point is "what is the target?".

I believe "git reset" is targeting at the index file and only the
index file and nothing more. it's that simple.

what we want instead is a command to sync/reset/revert both index and
tree to know working point.  so this isn't core plumbing but as a user
of git, i'm sure it's very handy to have it.

--soft one is simple to think, so i'm starting with this one. let's
assume that, as you described in the original post, this one is
intended to be used to rework on the work _you_ have before.  that
means that _you_ know exactly what you are doing.

there might be a case, and this happned to me quite some time when I
was working with quilt, which you don't want to automatically add all
the files you added on the privious commit. ie. moving defines from
header to .c, splitting a work to two commits.

so in this case, it's ideal to just use "git reset" if the command
lists files removed from the index.

for --hard option, what you want to do is to completely revert the
current state of your index file and work tree to known point.

for that, how about git-revert-script?  can we add --force option to
that command so that even if your working tree is dirty it reverts to
the specified point?
--
          yashi