Luis Ressel <aranea@xxxxxxxx> writes:
> currently "git commit --only <file>" only works if <file> is already
> checked into the repo, but not with newly created and still untracked
> files (builtin/commit.c:list_path() throws the error "error: pathspec
> '<file>' did not match any file(s) known to git.")
The fact that pathspec on the command line of "commit" does not let
you add new files is true with or without "--only". Yes, "--only"
is the default so with or without it it means the same thing, but
even with "--include" that says "I am happy with what is in the
index, but please take further changes to these paths, too" does not
affect files that are not so far tracked.
> I don't think this limitation is intented.
This actually was intended. Back when "commit [--opts] <pathspec>"
was invented, out tools were designed to avoid adding unwanted files
by mistake (e.g. "update-index" without an explicit "--add" work
only on paths already known to Git), and the behaviour is in line
with that design. It partly was because back then we didn't even
have ".gitignore" mechanism, I would say. So it was not only
intended, but was a sensible design decision back then.
I suspect that an argument could be made that it is about time we
shift the design philosophy and allow adding new paths with pathspec
given to "git commit". If I were designing Git without any existing
users, with all the other goodies we already have, and "git commit"
in my version of Git lacked pathspec support now, I might allow it
to add untracked files with the pathspec [*1*].
There however are backward compatibility worries. People who are
used to the designed behaviour for the past 10 years still expect
and rely on that
$ git commit <path-to-dir>
to take _only_ changes to the files that are already tracked in the
<path-to-dir> since the last "git add" they did to them, and other
files in the same <path-to-dir> that are not yet ready (and they
deliberately left un-added) will not be in the commit.
[Footnote]
*1* I might decide not to, after thinking long enough, though. The
point is that times changed and the trade off between safetly of
not adding at the point of commit and convenience of adding has
shifted. I haven't thought enough to decide that the shift is
big enough to warrant the change in behaviour, but at least it
is now worth considering.