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

Patrick Häcker  <patrick.haecker@lss.uni-stuttgart.de> writes:

This and its extreme form "git commit *" (also "git update-index *"), do not to touch untracked files. It was a very conscious and deliberate design to avoid mistakenly adding unnecessary/unwanted cruft, e.g. object files and editor backups, to the index. The primary reason we were extra careful about adding cruft by fat fingers was because these operations came before we had usable .gitignore support (in other words, this design is back from Linus's git days in early 2005).

In theory, as we have gitignore support, we now could change them and the end result would arguably be more consistent _as long as_ you always maintain spiffy-clean gitignore list, but you need a very careful planning to migrate existing scripts and millions of users' fingers without breaking them. Currently, the safety kicks in if you do this:

	$ >testing-01.c
        $ git commit *.c *.h
	error: pathspec 'testing-01.c' did ot match any file(s) known...

and people are used to and do rely on this safety to keep them from accidentally committing throw-away experiments, debugging aids, etc. You could argue that people _should_ teach their gitignore about "testing-*.c" but in practice that won't fly because throw-away stuff bye their own nature come and go without planning, and catching things in gitingore pattern is all about planning.

We discussed "git commit -A" for this exact purpose in the past. It is just as error prone as making "git commit *" to add new paths, but "-A" has a distinct advantage that it is _explicitly_ asking to add new paths, and also it did not exist so there is no migration to worry about.

No need to say this, as the convention on this list is never cull Cc: unless there is a good reason.