From: Kang-Che Sung <explorer09@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: Combined diff format: Show all filenames by default?
Date: Sat, 4 May 2024 06:25:35 +0800 [thread overview]
Message-ID: <CADDzAfN4gXVcqUVdoA12Z+o63JbsTk8zUpNdiVFSFmTFZtrVzg@mail.gmail.com> (raw)
In-Reply-To: <xmqqjzka65ry.fsf@gitster.g>
On Sat, May 4, 2024 at 3:42 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> >> As the format HAS ALREADY lasted for a long time since its
> >> introduction in d8f4790e (diff-tree --cc: denser combined diff
> >> output for a merge commit., 2006-01-24), it is too late to change
> >> the default.
> >
> > I wonder what things would break if we change the default behavior of this?
>
> Human users who rarely if ever rename files will start complaining
> for wasted vertical screen real estates taken by the extra lines.
>
> Nothing is broken, and you are proposing to break things. Be more
> gentle to existing users; "what would break if we change?" is an
> absolutely wrong attitude to approach this.
I would disagree with this.
1. Most uses of diff command are on a scrollable terminal screen (with
"less", "vi", or another text editor). It's just one line of vertical
screen taken - very subtle unless you have 4-way or more diffs. And
it's not just about renames. It's a much easier indicator that the
diff is a multi-way comparison.
2. It's a usability problem - like an Ok/Cancel dialog that took years
to realize they are badly designed. I consider the two filename only
header lines a "paper cut" usability bug. Git is able to output more
than two filenames; it just doesn't have a way to make it the default
(even as a per-user default option).
>
> > Well, I won't expect the default to be changed for uses in scripts or
> > GUI frontends. I wish to change the default for interactive, terminal
> > uses, so that usability comes in "out of the box".
>
> How would a script that is running by interactive users whose
> standard input and output streams are connected to a terminal adjust
> to sudden change of the default? The "git" invocation in such an
> environment would not be able to tell if you typed it or if you
> typed the name of the script.
>
How is it _not_ possible to tell? If user runs "git diff" from the
script, then it would just print to standard output without running a
"less" pager. If I want to execute a set of commands with
interactivity, I would write a script and then "source my-script-name"
rather than "./my-script-name", so it's still possible to tell.
prev parent reply other threads:[~2024-05-03 22:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-03 2:06 Combined diff format: Show all filenames by default? Kang-Che Sung
2024-05-03 14:57 ` Junio C Hamano
2024-05-03 19:11 ` Kang-Che Sung
2024-05-03 19:42 ` Junio C Hamano
2024-05-03 22:25 ` Kang-Che Sung [this message]
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=CADDzAfN4gXVcqUVdoA12Z+o63JbsTk8zUpNdiVFSFmTFZtrVzg@mail.gmail.com \
--to=explorer09@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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).