Hello, I introduce git to students and thus see, where they have a harder time than necessary to understand git. Thus, I was thinking about a CLI improvement regarding "git commit". It follows from the observation, that the staging area is a very valuable thing, but it should not be needed for very simple workflows and thus should not be the first concept, the students have to learn about. After a file has been added to the repository once, you can use git without knowing anything about the staging area, with "git commit ". Shouldn't we allow "git commit " for files never added to git, as well? Then, IMHO this would be more consistent, as in a small project a typical commit (with a new file) consists of adding a new file to the repository and changing an existing file (e.g. to call a function located in the new file). ATM this is done with "git add && git commit". But as we track content and not files, it were perfectly logical, if "git commit " were possible, as then it were completely consistent to only change an existing file without adding a new file, which is "git commit ". So I suggest to change "git commit " so that if cannot be found in the repository, it is also looked for in the working directory and basically a "git add && git commit" is done if the is found. I do _not_ suggest to change "git commit -a" to include all files never added to git, because that would be rather error prone. So after the change we would have an inconsistency between "git commit " and "git commit -a", but I think this inconsistency is better than having the inconsistency between "git commit " and "git commit ". Kind regards Patrick P.S. Please CC, as I am not subscribed -- Patrick Häcker Universität Stuttgart Lehrstuhl für Systemtheorie und Signalverarbeitung Tel: +49 711 685 67362 E-Mail: patrick.haecker@lss.uni-stuttgart.de URL: http://www.lss.uni-stuttgart.de