Git Mailing List Archive mirror
 help / color / mirror / Atom feed
From: Kang-Che Sung <>
To: Junio C Hamano <>
Cc: Git List <>
Subject: Re: Combined diff format: Show all filenames by default?
Date: Sat, 4 May 2024 06:25:35 +0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <xmqqjzka65ry.fsf@gitster.g>

On Sat, May 4, 2024 at 3:42 AM Junio C Hamano <> 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.

      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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* 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).