From: Junio C Hamano <gitster@pobox.com>
To: Sergey Organov <sorganov@gmail.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>,
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 09:26:25 -0700 [thread overview]
Message-ID: <xmqqpm76ygum.fsf@gitster.g> (raw)
In-Reply-To: <871qjn2i63.fsf@osv.gnss.ru> (Sergey Organov's message of "Thu, 11 May 2023 14:59:00 +0300")
Sergey Organov <sorganov@gmail.com> writes:
> That said, there is another mystery in the diff interface as well: why
> do we have --patch-with-raw and --patch-with-stat, yet no
> --raw-with-stat, --numstat-with-shortstat, --patch-with-numstat, etc.?
> If, say, --patch turned off everything except usual diff output, then
> these combinatorical options would make sense, but currently they don't.
I can explain the mystery but the explanation may or may not justify
it, depending on how lenient you are to developers of old days, with
less experience than they have today ;-).
Back when we started, "--raw" was the only thing there, and then we
were to pass the raw-to-patch external filter, when you wanted a
patch output. I then updated this arrangement to work in a single
process [*] without having to produce textual hexadecimal output
(raw) and piping it to another process, and that is how "--patch"
mode was created [*].
After I added "--patch", without having foresight of the risk of the
combinatorial explosion, "--patch-with-raw" was born. "--stat" and
other niceties came much later, and made me finally realize the risk
of the combinatorial explosion. "--patch-with-raw" stopped gaining
siblings as a consequence.
Yes, I was slow and inexperienced, but one has to do with the
capability one has at the time.
> Finally, there is another intrinsic problem in current Git CI: the
> "defaults to" part, as in "git show" that defaults to --patch for simple
> commits, --cc for merge commits, etc., except that it doesn't behave as
> if these options were explicitly provided at the beginning of the
> command-line.
Yes, as you said in your message after this part, this is pretty
much deliberate and is done for the sake of usability. Essentially
the logic is to achieve two distinct goals:
* we want to be able to combine the basic things like --patch,
--raw, --stat to specify exact format (but some things may not
mix well with others).
* when the user does not give a specific preference, we want to
give a reasonable default.
So, when the user wants "--stat", we do not want to combine it with
"--patch" that the user may have gotten by default if they did not
give "--stat". If we implemented the default logic like the way (I
guess) you are suggesting, i.e.
* there is a default set of options, "--patch".
* the user can add or subtract options with "--[no-]foo" where the
value of foo may be patch, stat, etc.
it would turn it to "--patch --stat" if the user gave "--stat" on
the command line. The user needs to say "--no-patch --stat" if they
want to see only the diffstat (which by itself is not necessarily
bad; if it is more common to want --patch-with-stat than --stat, it
may even be better), but the bad part is that the user need to
remember what the built-in default is.
[Footnote]
* Not exactly a "single process"; until Linus imported xdiff
machinery to make the textual patch generation in-process, we
forked "diff -u" as a subprocess inside "git diff-*". But the end
user no longer had to construct the "git diff-files | raw-to-patch"
pipeline themselves.
* Eventually it would become the in-process "diffcore transformation
pipeline" to compute diff_queue, which is a moral equivalent of
the input to "raw-to-patch filter", then transform the result of
the previous step (e.g. rename detection) and then format the
result of the previous step into various output, but none of that
existed back then.
next prev parent reply other threads:[~2023-05-11 16:26 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 [this message]
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
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=xmqqpm76ygum.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=matthieu.moy@univ-lyon1.fr \
--cc=sorganov@gmail.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 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).