Re: [PATCH] reset: Better warning message on git reset --mixed <paths>

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Regarding the various modes that are forbidden with "reset", I've been
wondering if we can do things differently.

If you want to reset the index at selected paths, don't use any option, as
nothing but --mixed makes sense.  Hence we deprecated use of --mixed when
used this way.  But if _it_ makes sense, why deprecate it?  What harm
would it do if we took it silently?

IIRC, the reasoning that lead to the deprecation was that allowing --mixed
may give a false impression to confused users that other mode options also
might be usable with pathspec, e.g. "reset --soft [<commit>] <pathspec>".
It obviously should barf loudly, as there is no way to move the HEAD to a
named commit without touching the index and the worktree at only specified
paths, but then the error message belongs to --soft, not --mixed.

Also "reset --hard [<commit>] -- <pathspec>" is forbidden in a repository
with a working tree, but it is clear that what the user wanted to do with
that unsupported command was what "checkout [<commit>] -- <pathspec>"
would have done.

What if we:

 - change "reset --hard [<commit>] -- <pathspec>" to internally run the
   moral equivalent "checkout" without complaining;

 - change "reset --mixed [<commit>] -- <pathspec>" to do the same thing as
   it has always done without complaining; and

 - make sure "reset --soft [<commit>] -- <pathspec>" barfs loudly.

Do people see major downside?
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]