git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Carl Worth <cworth@cworth.org>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: Two crazy proposals for changing git's diff commands
Date: Thu, 09 Feb 2006 15:44:20 -0800	[thread overview]
Message-ID: <87bqxgxfl7.wl%cworth@cworth.org> (raw)
In-Reply-To: <7vfymtl43b.fsf@assigned-by-dhcp.cox.net>

[-- Attachment #1: Type: text/plain, Size: 4779 bytes --]

On Wed, 08 Feb 2006 17:21:12 -0800, Junio C Hamano wrote:
> Carl Worth <cworth@cworth.org> writes:
> > Can anyone else think of common use cases for these various
> > operations that I've missed?
> 
> If there is none, then that means we have covered everything.
> But a more interesting question to ask is "are there useful
> comparisons that the existing diff lowlevel does not give me
> with a single command".  And the answer is of course yes.

Yes, that's a more useful way to ask the question.

> For example, you cannot preview "git commit --include paths..."
> with a single low-level command.  You would need to run
> "git-diff-index --cached HEAD" for paths that are _not_
> specified, and "git-diff-index HEAD" output for paths that you
> will give to "--include" when you make that commit.

Personally, I see that as an argument against adding the --include
semantics. It's a single command that is committing a mix of the index
and the current files, (which neither "commit" nor "commit -a"
do). Granted, Linus has said that he has relied on these existing
semantics, (but he also conceded willingness to retrain to
"update-index paths; commit" instead).

So there's some food for though there.

> Of course, learning various flags to give "git diff" is part of
> understanding the index, so if the user understands index, "git
> diff" without arguments will _not_ be the only diff command the
> user uses for a preview.  And I suspect that depending on what
> development style you would use, the definition of "useful
> comparisons" would be different.

Yes, and I think it would be nice if the different workflows could be
captured by different subsets of commands, (rather than a mishmash of
different options to the same commands).

For example, I *think* we have consensus that two different, equally
reasonable, workflows might currently use the following sets of
commands (this is for basic work-preview-commit):

Index-lover:

	update-index
	diff --cached
	commit

Index-ignorer:

	diff HEAD
	commit -a

So, what I'm trying to work towards is a situtation where those
workflows are captured through obviously-correlated command
subsets. This is what I was getting at in the PS. of my previous
post. For example, the above could be, (ignoring the clash with
existing core commands), something like:

Index-lover:

	update-index
	diff-index
	commit-index

Index-ignorer:

	diff-files
	commit-files

[Note that due to the name clash problems, I'm not making a serious
proposal here---merely showing again the consistent naming I'm
interested in.]

The point of an exercise like that is that people could then settle on
appropriate workflows by reading a small subset of man pages that link
to each other, in their entirety. Compare that with the previous
command examples where the workflow is documented in little subsets of
man pages scattered about.

And please pardon me for my current fixation on the learnability of
git, but I am in the situation of "selling" git to my fellow
maintainers, (some of whom are saying "mercurial looks easier to
learn").

> No, the goal should be for normal workflows there should be *no*
> need to use lowlevel commands by end users day-to-day.

Sure. In that light, try to conceive as my proposed "diff-files" and
"diff-index" commands as two new highlevel commands. They would be
useful in day-to-day operation, and most commonly without any need for
command-line arguments. Those two operations exist today within the
git-diff wrapper already as "diff HEAD" and "diff --cached HEAD" (or
"diff --cached). But as described above, I think it would be better to
put these operations on separate command names, and get them down to
not requiring any command-line arguments in their common usage.

> I have not typed lowlevel commands from the command line for
> quite a long time, except when I am debugging, and except when I
> wanted to see "diff-tree --cc" output for a single commit, only
> because there was no suitable wrapper. 

If you compare my above two chunks of example commands, there's nothing
like a low-level vs. high-level distinction between them. It's more
about separate command names being uses for different use cases and
consistent naming used to group related commands within a use case.

>                                        The last reason is now
> gone thanks to "git-show" Linus added.  So as far as *MY*
> workflow is concerned, that goal has already been achieved.

I confess that prior to reading the replies from you and Linus I had
never heard of git-show. I'll go look at that now, as well as consider
the suggestion to extend git-status to give me what I'm looking for.

Anyway, thanks for all the patience. I'm really enjoying the
conversation, and I hope I'm not being a bore.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2006-02-09 23:45 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   ` Carl Worth [this message]
2006-02-10  0:13     ` Two crazy proposals for changing git's diff commands 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
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=87bqxgxfl7.wl%cworth@cworth.org \
    --to=cworth@cworth.org \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    /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 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 NNTP newsgroup(s).