Hi, > The result is conceptual complexity and rather counter-intuitive > behavior. For example, adding and renaming files outside of Git is > not considered editing the version until you subsequently do a "Git > Add ." Contrast that with editing or deleting files outside of Git. > Yet adding and renaming files and folders is a significant part of > substantive projects, especially in the early stages and experimental > branches. yet even now, people routinely add huge amounts of files they didn't actually want to add, and then have to expend a huge amount of effort to get them out of the history again (particularly if that history has already been published). What you are describing is a workflow that is even fuller of potential for wrong turns than the current standard workflow is. If simplicity leads to a greater potential for errors, how is it a good thing? This kind of workflow actually involves more work for the user. She now has to meticulously maintain an accurate list of ignore patterns, particularly because of this: > Also can we augment checkout to totally CLEAN the working directory > prior to a restore. If necessary we can augment .gitignore to > stipulate those files or folders that should be excluded from the > cleaning. So if I forget to add a certain pattern, my file is lost forever? Uhh... > This suggestion is in recognition of the fact that if you > are not versioning the file, it is typically trash Just how typical is that, though? I wouldn't want to be the one to judge that. In light of my concerns, I oppose adding your suggestions to the official CLI of git and I suggest that you create your own commands to enable this kind of workflow. For example: git config --global alias.commitx '!git add . && git commit' git config --global alias.checkoutx '!git clean && git checkout' Jan -- 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