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:
pgpVD7PVeadWl.pgp
Description: PGP signature