From: Junio C Hamano <gitster@pobox.com>
To: kristofferhaugsbakk@fastmail.com
Cc: git@vger.kernel.org, Kristoffer Haugsbakk <code@khaugsbakk.name>
Subject: Re: [PATCH v2] Revert "doc: move git-cherry to plumbing"
Date: Mon, 13 Jan 2025 08:56:09 -0800 [thread overview]
Message-ID: <xmqqv7uiac0m.fsf@gitster.g> (raw)
In-Reply-To: <e5b20f9ceb437a82c422136cb81b05a0521cab07.1736682716.git.code@khaugsbakk.name> (kristofferhaugsbakk@fastmail.com's message of "Sun, 12 Jan 2025 12:54:28 +0100")
kristofferhaugsbakk@fastmail.com writes:
> From: Kristoffer Haugsbakk <code@khaugsbakk.name>
>
> This reverts commit 61018fe9e005a54e18184481927519d64035220a.
>
> git-cherry(1) is a high level command for checking what commits have and
> have not been applied to some other branch. Or at least as high level
> as the git(1) suite offers. In other words:
>
> • it is a useful interrogator for a particular workflow; and
> • there are no higher level commands on offer.
>
> By contrast its use for scripting is somewhat narrow since it only
> prints the patch application status and the hashes of the downstream
> branch (not also the upstream branch equivalents). git-patch-id(1)
> gives a fuller picture by printing each hash and its corresponding
> patch id.
>
> Now this command is not nearly as convenient for the purpose of deleting
> a *merged* branch as:
>
> git branch -d <branch>
>
> Since that command will refuse to delete the branch if the commits are
> not in the configured upstream ref. But again it is the most convenient
> command for the patch workflow.
>
> This command might only be considered plumbing by way of the plumbing
> contract that says that plumbing commands have stable output. But
> hopefully listing this command as Porcelain does not give the impression
> that the output is not stable. Output stability was in any case not the
> motivation for moving this command to plumbing.
I do not follow the above reasoning at all.
It is not like it is a crime to intarctively make use of a plumbing
command, or we intentionally try to hide plumbing command from them
by making it deliberately less accessible. "git cat-file commit X"
may be handier than "git show -s X" for some people and that is not
to be frowned upon.
And what you call "might only be" is really the crucial thing to
consider. If we want to keep a tool's output stable and machine
readable, we need to mark it as "meant for Porcelain writers", and
classifying the tool as plumbing is a pretty much established way to
do so.
next prev parent reply other threads:[~2025-01-13 16:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-12 11:54 [PATCH v2] Revert "doc: move git-cherry to plumbing" kristofferhaugsbakk
2025-01-12 12:30 ` Kristoffer Haugsbakk
2025-01-13 16:56 ` Junio C Hamano [this message]
2025-01-14 10:24 ` Kristoffer Haugsbakk
2025-01-14 17:35 ` Junio C Hamano
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=xmqqv7uiac0m.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=code@khaugsbakk.name \
--cc=git@vger.kernel.org \
--cc=kristofferhaugsbakk@fastmail.com \
/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.