Carl Worth wrote: > Change #2: Make a staged commit an explicit act > =============================================== > The "-a" stands out to me here as the only command-line option needed > in the first list, and the only command in the second list that > performs a staged operation by default. So change number to is to > redefine "commit" to mean what "commit -a" meant before and to require > a new command-line option for staged committing, (the best naming I > have so far is "commit --staged" with a shortcut of "commit -i"---the > mismatch of "'i' as short for --staged" is a bit unlovely I admit). I wonder about backwards compatibility, but then another part of me says that porcelain are probably using "git-commit-tree" anyway. How about considering alternative words? Like "git save" for this higher level and more user friendly interface. As another idea (brainstorming here), what about an "autocommit" approach? git rm # removes files and asks for commit message git add # ditto git commit # updates and commits everything git stage # starts a staged commit git add # modifies staging area git rm # ditto git stage filename # adds contents to staging area git commit # saves staging area as commit Then you could have "core.autocommit" as a repo-config option, defaulting to off for "backwards compatibility". > Change #3: Change "add" to not stage any content > ================================================ > To finish off, I'd like to propose descriptions of the commands to > allow the user to use the "without staging" commands as a complete set > while being able to easily ignore any of the staging capabilities. > This does trigger a need for a semantic change in the "add" > command. Here are the proposed descriptions: The "autocommit" concept may make this less of an issue. Sam. - 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