All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Michael J Gruber <git@grubix.eu>, Jeff King <peff@peff.net>,
	Junio C Hamano <gitster@pobox.com>
Cc: Bagas Sanjaya <bagasdotme@gmail.com>,
	Felipe Contreras <felipe.contreras@gmail.com>,
	git@vger.kernel.org, Jonathan Nieder <jrnieder@gmail.com>,
	Matthieu Moy <git@matthieu-moy.fr>
Subject: Re: [PATCH 6/7] stage: add 'diff' subcommand
Date: Wed, 11 Aug 2021 16:40:59 -0500	[thread overview]
Message-ID: <611443ebea222_1ed62089f@natae.notmuch> (raw)
In-Reply-To: <162871314612.7067.6886805754107701040.git@grubix.eu>

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@mfriebe.de/
[2] http://lore.kernel.org/git/20210702100506.1422429-1-felipe.contreras@gmail.com

-- 
Felipe Contreras

  parent reply	other threads:[~2021-08-11 21:41 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-11  4:57 [PATCH 0/7] [un]stage: officially start moving to "staging area" Felipe Contreras
2021-08-11  4:57 ` [PATCH 1/7] stage: add proper 'stage' command Felipe Contreras
2021-08-11  4:57 ` [PATCH 2/7] stage: add helper to run commands Felipe Contreras
2021-08-11  4:57 ` [PATCH 3/7] stage: add 'add' subcommand Felipe Contreras
2021-08-11  4:57 ` [PATCH 4/7] stage: add 'remove' subcommand Felipe Contreras
2021-08-11  4:57 ` [PATCH 5/7] unstage: add 'unstage' command Felipe Contreras
2021-08-11  4:57 ` [PATCH 6/7] stage: add 'diff' subcommand Felipe Contreras
2021-08-11  6:12   ` Bagas Sanjaya
2021-08-11  7:24     ` Felipe Contreras
2021-08-11 16:00     ` Junio C Hamano
2021-08-11 17:17       ` Felipe Contreras
2021-08-11 19:06       ` Jeff King
2021-08-11 20:18         ` Felipe Contreras
2021-08-11 20:30           ` Jeff King
2021-08-11 21:24             ` Felipe Contreras
2021-08-11 20:19         ` Michael J Gruber
2021-08-11 20:40           ` Jeff King
2021-08-11 20:51             ` Michael J Gruber
2021-08-11 21:02             ` Jeff King
2021-08-11 20:57           ` Junio C Hamano
2021-08-11 21:40           ` Felipe Contreras [this message]
2021-08-11  4:57 ` [PATCH 7/7] stage: add 'edit' command Felipe Contreras
2021-08-11 10:44 ` [PATCH 0/7] [un]stage: officially start moving to "staging area" Michael J Gruber
2021-08-11 16:55   ` Felipe Contreras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=611443ebea222_1ed62089f@natae.notmuch \
    --to=felipe.contreras@gmail.com \
    --cc=bagasdotme@gmail.com \
    --cc=git@grubix.eu \
    --cc=git@matthieu-moy.fr \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.