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

From: Jeff King <peff@peff.net>
Date: Aug 11, 2021, 20:40 UTC
Message-ID: <YRQ11bYH5lV9D24D@coredump.intra.peff.net>
In-Reply-To: <162871314612.7067.6886805754107701040.git@grubix.eu>

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

Show 20 quoted lines

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

Show 14 quoted lines

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

Show 5 quoted lines

> 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