Re: [PATCH 6/7] stage: add 'diff' subcommand

On Wed, Aug 11, 2021 at 10:19:06PM +0200, Michael J Gruber wrote:

quoted

quoted

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).

One thing I find off-putting about "git stage --diff" is that to me,
"stage" reads as a verb. So it is like "git add --diff", which seems
out-of-place; there are two verbs in a row.

I do not mind the term "staging area", but using "the stage" as a noun
is simply confusing to me in this context.

I think this exemplifies what I meant by discussing things in order. The
concept "staging area" works in teaching and explaining things. But
that does not imply that a "stage command" is the best way to convey
that concept in the UI.

Yeah, I agree very much that saying "the term staging area makes sense"
does not imply that the "stage command" is a good idea.

I mean, so much of git is about operating on or comparing between three
different types of "sources": the working tree, the index, a treeish. A
lot of confusion comes from the fact that we hide this behind different
commands to act on them and different ways to specify these conceptual
items:
- You specify a treeish as an argument to a command.
- You specify the index as an option (--cached, --staged) or by choosing
  the right command.
- You specify the working tree as an option (--worktree) or by choosing
  the right command (checkout vs. reset) or number of options (diff).

Newer commands like "restore" try to help but fail badly when e.g. "restore
--staged" means you overwrite what is staged with something from a
treeish.

Agreed. At one point[1] I half-proposed a "git put" command that would
move changes between those three places (and giving a concrete name for
the index and working tree so they could be specified as sources or
destinations).

I do still like it as a conceptual model, but IIRC it gets hairy in some
of the details (e.g., "checkout -p HEAD" is still using the index as an
intermediary).

I still think it's very worthwhile to fantasize about a git which has
only verb-like commands (such as diff, add, checkout, checkin) and a
consistent way of specifying the objects to act upon (possibly amended
by "git pluralnoun" being synonymous to "git ls noun" or similar
convenience shortcuts).

I don't really disagree with anything in your post, but I do think a
pure-verb world would be tricky in some ways. Or at least verbose. We
have "git branch --delete". But "git delete" seems a little too
open-ended. The concept of that verb is meaningful only in the context
or a particular noun. We could call it "git delete-branch", but that
doesn't really seem to make the world a better place. :)

-Peff