Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".

[Carl Worth <cworth@cworth.org>]

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

On Thu, 30 Nov 2006 12:37:49 -0500 (EST), Nicolas Pitre wrote:
> Might it be a good idea to have "git-add" do the same as
> "git-update-index" on already tracked files?  That could be easily
> taught as "you must explicitly _add_ files to your next commit"

I think this is worth doing, but it doesn't solve the problem.

It would be nice if this worked, because then it would be natural to
teach users to "git add" their changes, and then when the obvious
complaint about that being annoying to type all the time, then respond
by teaching "git commit -a" as a shortcut. That would be very natural.

But this doesn't quite work. Here's a major "index is confusing"
scenario that I first hit on my first exposure to git, (it was so long
ago that I completely forgot about it when when Linus asked what the
big deal is about the index).

It's all about the fine details of what "git add" does that can be
_extremely_ surprising to new users. Here's a simple scenario:

	$ git init-db
	defaulting to local storage area
	$ echo "hello wurld" > hello
	$ git add hello

	# Oops! Look at that typo.

	$ echo "hello world" > hello
	$ git commit -m "add hello"
	Committing initial tree 0267c1bf2956b3df47851e0163f2ea86c002379d
	$ git diff
	diff --git a/hello b/hello
	index b1df5e6..3b18e51 100644
	--- a/hello
	+++ b/hello
	@@ -1 +1 @@
	-hello wurld
	+hello world

And here the new user reaction is "What?! I fixed that before I
made the commit! What kind of broken system is this."

The above example is not at all surprising to someone who understands
the index. And it's that "why should that behavior be confusing"
disconnect that I'm trying to bridge here. Can you see why the above
confuses new users?

In most other systems I've used, 'add' means "I want the system to
'know' about this file" while 'commit' means "Please commit the
current state of all files you 'know' about (or the ones I mention
here on the command line)".

The current semantics do nothing to avoid this "interaction bug" and
there is no way to explain it to the user without going through an
"explanation of the index" and the user is left to decide that the
index is just there to help make broken commits.

So, I'd love for "git add" to be a shorter way to type "update-index",
(I have been campaigning for eliminating hyphens after all), but
without different semantics _somewhere_ the default behavior still is
potentially very confusing. The "ignore the index" stance Linus has
been proposing recently just doesn't work here.

And all of this contributes to make git harder to learn than it should
be.

-Carl

PS. It was actually "hard" for me to create that example above. The
first time I ran through the commands I ended up with an empty diff at
the end. "Huh? I _know_ that git does surprising things here." That
was because I was using Junio's "commit -a" patch which did right
thing rather than demonstrating the old wrong behavior I was trying to
demonstrate.

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