All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: git@vger.kernel.org
Subject: Re: Two crazy proposals for changing git's diff commands
Date: Sat, 11 Feb 2006 19:48:54 -0800	[thread overview]
Message-ID: <7vr769fd95.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <20060212031527.GA31228@fieldses.org> (J. Bruce Fields's message of "Sat, 11 Feb 2006 22:15:27 -0500")

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

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

  reply	other threads:[~2006-02-12  3:48 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-09  0:29 Two crazy proposals for changing git's diff commands Carl Worth
2006-02-09  1:05 ` Linus Torvalds
2006-02-09  1:21   ` Linus Torvalds
2006-02-09 23:07     ` Carl Worth
2006-02-09 23:40       ` Junio C Hamano
2006-02-09  1:35   ` Junio C Hamano
2006-02-09  1:21 ` Junio C Hamano
2006-02-09  1:30   ` Linus Torvalds
2006-02-09  1:37     ` Junio C Hamano
2006-02-10  9:05     ` Junio C Hamano
2006-02-10 20:32       ` Comments on "status -v" (was: Two crazy proposals for changing git's diff commands) Carl Worth
2006-02-10 21:09         ` Comments on "status -v" Junio C Hamano
2006-02-10 21:35           ` Linus Torvalds
2006-02-10 22:12             ` Junio C Hamano
2006-02-10 22:51           ` Petr Baudis
2006-02-10 23:26             ` Junio C Hamano
2006-02-09 23:44   ` Two crazy proposals for changing git's diff commands Carl Worth
2006-02-10  0:13     ` Junio C Hamano
2006-02-10  1:24       ` Carl Worth
2006-02-10  2:24         ` Junio C Hamano
2006-02-10  3:18           ` Carl Worth
2006-02-10 17:06           ` Mark Wooding
2006-02-13  9:23             ` Catalin Marinas
2006-02-13 22:00             ` Prune-safe StGIT (was Re: Two crazy proposals for changing git's diff commands) Catalin Marinas
2006-02-10 19:36           ` Two crazy proposals for changing git's diff commands Kent Engstrom
2006-02-11 19:25             ` Junio C Hamano
2006-02-12 12:00               ` [PATCH] Add howto about separating topics kent
2006-02-12  3:15   ` Two crazy proposals for changing git's diff commands J. Bruce Fields
2006-02-12  3:48     ` Junio C Hamano [this message]
2006-02-09 16:44 ` Tim Larson

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=7vr769fd95.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=bfields@fieldses.org \
    --cc=git@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.