[feature request] Make "commit --only" work with new files

Hello,

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.")

I don't think this limitation is intented. I've had a look at the relevant part of builtin/commit.c, but unfortunately it wasn't obvious to me how to fix this.

Regards, Luis Ressel

Hi Luis,

On Fri, 25 Nov 2016, Luis Ressel wrote:

The best way to go about it is probably to define the desired behavior first, in the form of a patch to the test suite. Personally, I would extend t/t7509-commit.sh with a new test case.

Then, once you have that test case (that should be marked with test_expect_failure, because it fails for now), you can use a debugger such as gdb to single-step into the relevant function (I guess "prepare_index()" is a good candidate) to find out why the files are not added.

From there, it should be easier to figure out what to patch, and how.

Good hunting! Johannes

Luis Ressel <aranea@aixah.de> writes:

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.

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.