One thing that I think is non-intuitive to a lot of users (either novice or who just don't do it much) is that it matters where in the process you do "git add <path>" if you're also changing the file. Even if you understand the index, you may not realize (or may not have internalized the fact) that what git-add does is update the index with what's there now. I think the more obvious behavior is to have it record the fact that you want to have the path tracked, but require one of the usual updating mechanisms to get a particular content into the index. This should be pretty simple to implement: use --cacheinfo 0 0 $path instead of --add -- $path, and teach programs that look at the objects recorded in the index (rather than just hashes or other info) about all-0 hashes meaning "but no content there". write-tree would probably just skip the entry (and then you could add a file, but still produce commits without it until you actually do either an update-index explicitly or one of the commit option sets that updates it); diff would treat it as empty; checkout would ignore it. -Daniel *This .sig left intentionally blank* - 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