Improvement of git commit interface

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 <filename>". Shouldn't we allow "git commit <filename>" 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 <newfile> <oldfile> && git commit". But as we track content and not files, it were perfectly logical, if "git commit <newfile> <oldfile>" were possible, as then it were completely consistent to only change an existing file without adding a new file, which is "git commit <oldfile>".

So I suggest to change "git commit <filename>" so that if <filename> cannot be found in the repository, it is also looked for in the working directory and basically a "git add <filename> && git commit" is done if the <filename> 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 <newfile>" and "git commit -a", but I think this inconsistency is better than having the inconsistency between "git commit <oldfile>" and "git commit <newfile>".

Kind regards Patrick

P.S. Please CC, as I am not subscribed