Junio C Hamano wrote:
> A more notable aspect of the above list is not the similarity but
> difference from the rest of Git. The above organizes various
> operations on the staging area in a single command as its operating
> modes, so you'd use "git stage --diff" for comparing with the
> staging area but use something else ("git commit --diff HEAD"???).
It is not different from the rest of git:
* git branch --delete
* git tag --delete
* git remote remove
* git stash drop
* git worktree remove
* git submodule add
* git config --edit
* git notes remove
* git bundle create
* git bisect start
Plus it's not unusual for commands and options to be redundant,
especially when they attempt to simplify or improve the user interface,
starting with `git checkout` / `git switch`.
> It is a good example that illustrates that the proposed organization
> may not help learning or using the system for operations that also
> apply to other things like commit and working tree (in other words,
> "git stage --grep" may not be such a good idea for the same reason
> as "git stage --diff"). But if it were limited to operations that
> apply only to the index (e.g. "git add" and "git rm"), it may be an
> improvement (I think we added "git stage" synonym exactly for that
> reason, already).
>
> Having said that, if we added "git stage --remove", there may be
> complaints that say "the stage command does too many things",
Or there might not.
> just like those that caused "checkout" to be split into "restore"
> (check out contents for selected paths in order to work on the current
> branch) and "switch" (check out a branch in order to start working on
> it). I dunno.
I don't see many people complaining that `git branch` does "too many
things", neither `git stash` or any of the commands listed above.
Moreover, you are not addressing the most interesting thing my proposal
enables:
git stage --edit
--
Felipe Contreras
