Patrick HÃcker <patrick.haecker@xxxxxxxxxxxxxxxxxxxx> writes:
> 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?
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.
> I do _not_ suggest to change "git commit -a" to include all files never
> added to git, because that would be rather error prone.
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.
> P.S. Please CC, as I am not subscribed
No need to say this, as the convention on this list is never cull Cc:
unless there is a good reason.
--
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