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

From: Junio C Hamano <junkio@cox.net>
Date: Feb 12, 2006, 03:48 UTC
Message-ID: <7vr769fd95.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060212031527.GA31228@fieldses.org>

"J. Bruce Fields" <bfields@fieldses.org> writes:

Show 9 quoted lines

> On Wed, Feb 08, 2006 at 05:21:12PM -0800, Junio C Hamano wrote:
>> 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.