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