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 22:32:54 +0300 [thread overview]
Message-ID: <87wn1ezms9.fsf@osv.gnss.ru> (raw)
In-Reply-To: <645d3dbf785a5_26069229463@chronos.notmuch> (Felipe Contreras's message of "Thu, 11 May 2023 13:10:55 -0600")
Felipe Contreras <felipe.contreras@gmail.com> writes:
> Sergey Organov wrote:
>> 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.
>
> But why?
>
> I don't see any benefit, only drawbacks.
>
>> > 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.
>
> But now you are at the mercy of those "arbitrary defaults".
No, see below.
>
> Let's say those defaults change, and now the default output of `git show` is
> `--stat`.
>
> Now to generate the same output you have to do:
>
> git show --raw
>
> in one version of git, and:
>
> git show --no-stat --patch --raw
>
> in another.
No: --raw in my model clears all the flags but --raw, so
git show --raw
will produce exactly the same result: raw output only.
Thanks,
-- Sergey Organov
next prev parent reply other threads:[~2023-05-11 19:33 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
2023-05-11 19:10 ` Felipe Contreras
2023-05-11 19:32 ` Sergey Organov [this message]
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=87wn1ezms9.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 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.