On Thu, 30 Nov 2006, Linus Torvalds wrote: > What does it mean to "add" something to a project? It has _nothing_ to do > with "filenames". Yeah, the filename obviously exists, but it's not > something that exists on its own. You add the ONLY thing that git tracks. > > You add CONTENT. > > When you do "git add file.c" you aren't adding a filename to the list of > files that git knows about. Not even CLOSE. No. You are really adding > _content_ to the project you are tracking. You haven't bound it to a > commit yet, but it's there. It's there both conceptually, and very much in > a real technical sense too (you've literally added the git object that > that file describes to the object database - the "commit" and "tree" > objects to tie it all together is just waiting to be added, but they > really just expose it - the actual file object has already been created > when you do "git add".) > > So yes, you very much ARE talking about CVS braindamage. The reason why > > git add file.c > echo New line >> file.c > git commit > > commits the _old_ content, is very much because git is ALL ABOUT THE > CONTENT. It has _never_ been about filenames. And it _shouldn't_ be about > filenames, because that would be BUGGY AND BROKEN. Great. But let me repeat my last question: Would it make sense for "git add" to do the same as "git update-index" on already tracked files? Given the explanation above this would make 100% sense to me. Even for newbies this might help them understand the power of the index with only one command. "You _add_ your changes together before you may commit." That's simple to understand even for newbies. And then they'll start using the power of the index even without realizing it. But right now, doing "git add" on an already tracked file simply does nothing. This is even worse than erroring out. Nicolas - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html