On Wed, Aug 11, 2021 at 10:19:06PM +0200, Michael J Gruber wrote: > > > 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
