Thread (1 message) 1 message, 1 author, 2016-06-15

Re: Two crazy proposals for changing git's diff commands

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:18

"J. Bruce Fields" [off-list ref] writes:
On Wed, Feb 08, 2006 at 05:21:12PM -0800, Junio C Hamano wrote:
quoted
Of course, learning various flags to give "git diff" is part of
understanding the index
Well, there's understanding the index, and then there's memorizing the
flags...
...
But maybe that's just me.  (And maybe the namespace in question is
already to crowded to allow for INDEX and WORK.)
I do not think it is just you.  The real problem, honestly
speaking, is that "git diff" wrapper cheats and avoids doing its
own set of flags.

The low-level is just a mechanism UI is built upon, and as a
mechanism, except perhaps maybe --cached might be now better
spelled as --index, has set of options and semantics that are
consistent with its world model (index centric way of thinking).

Because "git diff" wrapper cheats, it ends up exposing the
low-level flags and arguments to the end user, and to use that
effectively, obviously you need to understand the world model
the low-level is built upon.

It was OK (it could be argued that it was even better than sugar
coating to make it *inconsistent* with the underlying world
model) so far, as long as people who use it are aware of the
index centric world model, but that "consistency with the
underlying world model" makes it harder to approach and causes
confusion.

That is why I these days often mention "welding training
wheels".  Doing half-baked sugarcoating of the UI layer would
break mental model of people who understand the world model
low-level builds and tries to make effective use of low-level
through the UI.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help