From: Sergey Organov <sorganov@gmail.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org, Matthieu Moy <matthieu.moy@univ-lyon1.fr>
Subject: Re: Can we clarify the purpose of `git diff -s`?
Date: Thu, 11 May 2023 21:31:05 +0300 [thread overview]
Message-ID: <877cte200m.fsf@osv.gnss.ru> (raw)
In-Reply-To: <645d28e112294_26011a294b2@chronos.notmuch> (Felipe Contreras's message of "Thu, 11 May 2023 11:41:53 -0600")
Felipe Contreras <felipe.contreras@gmail.com> writes:
> Sergey Organov wrote:
>
>> I'd rather think about generic interface for setting/clearing
>> (multiple) bits through CI than resorting to such convenience
>> tricks. Once that is in place, one will be able to say "I need these
>> bits only", "I need to turn these bit(s) on", and "I need to turn
>> these bit(s) off" conveniently and universally in any part of Git CI
>> where it's needed.
>
> It's possible to achieve both.
>
> Imagine your ideal explicit interface. In that interface the default
> is no output, so you *have* to specify all the bits, for example:
>
> git show --patch
No, that's not what I meant. There is no point in making "git show" to
have no output by default, please see below.
>
> Or:
>
> git show --raw
>
> In this ideal interface it's clear what the user wants to do, because
> it's explicit.
>
> git show --patch --raw --no-patch
>
> Agreed?
>
> My proposal achieves your ideal explicit interface, except when no
> format is specified (e.g. `git show`), a default format is chosen for
> the user, but that's *only* if the user hasn't specified any format.
My point is that the default format should be selected as if it has been
provided by existing options, rather than by some magic hidden in the
code.
>
> If you explicitely specify the output format that you want, then the
> default is irrelevant to you, thus you have your ideal explicit
> interface.
That's not what I had in mind, sorry. It'd rather be something like:
--raw: set "raw" bit and clear all the rest
--+raw set "raw" bit (== current --raw)
---raw clear "raw" bit (== --no-raw)
In this model
git show
would be just an alias for
git log -n1 --patch --cc
and no support for a separate command would be need in the first place.
git show --raw
would then produce expected output that makes sense due to the common
option processing rules, not because somebody had implemented some
arbitrary "defaults" for the command.
Then one can even think about supporting some niceties like
git log --patch+raw
In other words, if we provide full orthogonal access to (the diff
output) bits using CL options, no special code wold be ever needed to
implement some niceties and shortcuts.
Disclaimer: please keep this with a grain of salt as this is not a
carefully thought-through proposal. Not yet anyway. Just me thinking
aloud.
For *nix guys, the closest analogy to the above is probably:
chmod og-wx
Thanks,
-- Sergey Organov
next prev parent reply other threads:[~2023-05-11 18:31 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-11 3:14 Can we clarify the purpose of `git diff -s`? Felipe Contreras
2023-05-11 11:59 ` Sergey Organov
2023-05-11 16:26 ` Junio C Hamano
2023-05-11 17:37 ` Junio C Hamano
2023-05-11 18:04 ` Sergey Organov
2023-05-11 18:27 ` Junio C Hamano
2023-05-11 18:36 ` Felipe Contreras
2023-05-11 18:17 ` Felipe Contreras
2023-05-11 17:41 ` Felipe Contreras
2023-05-11 18:31 ` Sergey Organov [this message]
2023-05-11 19:10 ` Felipe Contreras
2023-05-11 19:32 ` Sergey Organov
2023-05-11 19:54 ` Felipe Contreras
2023-05-11 20:24 ` Sergey Organov
2023-05-11 20:59 ` Felipe Contreras
2023-05-11 22:49 ` Sergey Organov
2023-05-11 23:28 ` Felipe Contreras
2023-05-12 8:40 ` Sergey Organov
2023-05-12 19:19 ` Felipe Contreras
[not found] ` <5bb24e0208dd4a8ca5f6697d578f3ae0@SAMBXP02.univ-lyon1.fr>
2023-05-12 8:15 ` Matthieu Moy
2023-05-12 17:03 ` Junio C Hamano
2023-05-12 18:21 ` Sergey Organov
2023-05-12 19:21 ` Junio C Hamano
2023-05-12 19:34 ` Junio C Hamano
2023-05-12 20:28 ` Felipe Contreras
2023-05-12 20:47 ` Junio C Hamano
2023-05-12 21:01 ` Felipe Contreras
2023-05-12 21:47 ` Junio C Hamano
2023-05-12 21:48 ` Junio C Hamano
2023-05-12 23:21 ` Felipe Contreras
2023-05-12 21:41 ` Sergey Organov
2023-05-12 22:17 ` Junio C Hamano
2023-05-12 22:47 ` Sergey Organov
2023-05-12 23:07 ` Felipe Contreras
2023-05-13 14:58 ` Philip Oakley
2023-05-13 17:45 ` Sergey Organov
2023-05-12 19:47 ` Felipe Contreras
2023-05-12 19:34 ` Felipe Contreras
2023-05-12 19:17 ` 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=877cte200m.fsf@osv.gnss.ru \
--to=sorganov@gmail.com \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=matthieu.moy@univ-lyon1.fr \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).