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

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

[Luis Ressel]

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

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

[Johannes Schindelin]

Hi Luis,

On Fri, 25 Nov 2016, Luis Ressel wrote:

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

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

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

[Junio C Hamano]

Luis Ressel <aranea@aixah.de> 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.