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

On Wed, 8 Feb 2006, Carl Worth wrote:

I would be using this before every "got commit" to get a preview, and
it seems like a painfully long name for such a common operation. Even
its shortcut form:

	git diff --cached HEAD

is among the longest of the "git diff" shortcuts.

[ snip snip ]

Yeah, I agree. The "git diff" semantics are incomplete, and the choices 
may not be (aka "almost certainly aren't") the best. The recent "git show" 
actually came from a very common use (well, for me, at least) for 
"git-diff-tree" that the "git diff" command simply didn't support.

I don't think it's really worth changing the low-level command naming: 
nopefully few enough people use them that it doesn't matter, but that's 
also what scripts out there are likely to have, so the pain factor when 
something breaks is high enough.

But making "git diff" itself more often "Do The Right Thing(tm)" would 
probably be a good idea.

In particular, I think the real culprit is the plain "git diff" with no 
arguments at all. Right now it ends up showing just a piece of the 
picture, and the piece it shows is incomplete enough to be irritating.

So I would prefer a slightly different fix from yours: instead of changing 
the core commands (which hopefully people mainly use in scripts where 
stability is more important than "intuitive and easy defaults"), how about 
_just_ changing the meaning of "git diff"?

Right now a plain "git diff" only shows the differences in the current 
tree against the index. I think that was just the wrong choice. I think 
almost everybody would actually prefer the default to be to show the 
difference against HEAD.

The largest reason for why "git diff" defaults to diffing against the 
index (and not head) is _literally_ that it's faster. Yes, I'm ashamed, 
but "git diff HEAD" takes 0.35 seconds for me, and "git diff" takes 0.07
seconds, and largely based entirely on that (and not "what would users 
want"), I made the bad choice to default to git-diff-files for the "no 
arguments" case.

I hang my head in shame. I just like the _instantness_ of "nothing 
changed". That's a bad reason for choice of interfaces, though.

One option is to realize that "git status" is actually a much better thing 
to use (because it shows _both_ the "HEAD to index" _and_ "index to 
current tree" format).

Teaching "git status" to take a "-p" flag (for "patch" - or -v for 
"verbose") might actually be a good thing. Then, instead of "git diff", 
you'd use "git status -p" and it would show you what the differences are 
in the index, and what they are in the tree, so you'd _really_ know what 
"git commit" in all its glory would do.

		Linus