Michael J Gruber wrote: > Therefore, "git stage" as an alias to "git add" does not serve the purpose > of establishing "staging area" very well, and "git stage --diff" shows > exactly the problem with turning an "object-like item" into a "verb-like > command". But "stage" can be a noun in English too. Just like "branch" can be both a verb and a noun. > 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). There was a sub-thread in which we fantasized a consistent UI [1], and taking Mercurial as inspiration the way to fix some of the warts would be: git branch # verb git branches new # noun verb git branches delete # noun verb Now, it's pretty unlikely that the inconsistencies with `git branch` will ever be fixed, but we can take that as guidance for the staging area: git stage # verb git unstage # verb git staging-area add # noun verb git staging-area remove # noun verb git staging-area diff # noun verb This I think would be the most consistent way of implementing this, my only problem is that 'staging-area' is too long. Of course users could easily write aliases, but git should be easy to use by default. If git implemented default aliases as I suggested [2], then I would have no problem with 'staging-area', because the user could simply do: git sa diff But that's a very big *if*. Cheers. [1] https://lore.kernel.org/git/f0770358-be4c-a747-0851-b2fd73c1978e@xxxxxxxxxx/ [2] http://lore.kernel.org/git/20210702100506.1422429-1-felipe.contreras@xxxxxxxxx -- Felipe Contreras
