# Bug: partially staged file is committed in whole, if there is another staged file

2 messages from 2014-08-17 to 2014-08-17. Participants: Paul Beckingham, Junio C Hamano.
Thread: https://gitlist.dev/t/37366

## Paul Beckingham, 2014-08-17 17:05

Subject: Bug: partially staged file is committed in whole, if there is another staged file
Message-ID: <96FA86FB-D017-470F-899F-EA0F6F28C1E4@beckingham.net>
URL: https://gitlist.dev/e/96FA86FB-D017-470F-899F-EA0F6F28C1E4%40beckingham.net

```
If I have two modified files, and file1 is staged (git add file1), and file2 is partially staged (git add -p file2), and then try to commit only the partially staged file2, git commits *all* changes to file2, not just the staged part.

There is no bug without file1 also being staged.

Here is a transcript illustrating the problem:

$ uname -v
Darwin Kernel Version 14.0.0: Tue Jul 29 16:22:25 PDT 2014; root:xnu-2782.1.62~4/RELEASE_X86_64

$ git version
git version 2.1.0

$ git status -sb
## master
M  file1
MM file2
$ git commit file2 -m "adding patch"
[master 066a6e2] adding patch
 1 file changed, 2 insertions(+)

$ git status -sb
## master
M  file1
$


Regards,
Paul
```

## Junio C Hamano, 2014-08-17 19:03

Subject: Re: Bug: partially staged file is committed in whole, if there is another staged file
Message-ID: <xmqq7g27ym4h.fsf@gitster.dls.corp.google.com>
URL: https://gitlist.dev/e/xmqq7g27ym4h.fsf%40gitster.dls.corp.google.com
In-Reply-To: <96FA86FB-D017-470F-899F-EA0F6F28C1E4@beckingham.net>

```
Paul Beckingham <paul@beckingham.net> writes:

> $ git status -sb
> ## master
> M  file1
> MM file2
> $ git commit file2 -m "adding patch"
> [master 066a6e2] adding patch
>  1 file changed, 2 insertions(+)
>
> $ git status -sb
> ## master
> M  file1
> $

You would likely to have seen

    $ git diff --name-only HEAD^ HEAD
    file2

This is a very deliberate design decision, and the command is
working as expected.  Here is why.

The filenames (technically, they are not filenames but pathspecs,
i.e. can be patterns to match the filenames) on the command line of
"git commit" are used to first "git add" them internally to form the
tree used for the next commit, and are not used to limit the paths
with changes that are already in the index.

I am not opposed to adding a new mode to use pathspecs to limit the
paths to be committed from the index without consulting the working
tree at all, but unless this is explicitly done as a new mode, you
would end up forcing people to say

    $ edit file3 file4
    $ git add file3
    $ git commit file3

while all existing users have been expecting that after modifying a
file "file3" and commit the changes to that file (and to no other
files), they can say

    $ edit file3 file4
    $ git commit file3

without the extra step of adding it.

We could however add a check to detect the case where your pathspec
matches a path that has changes both in the index and in the working
tree, and error it out.  To those who never use "git add", there is
no change to the path in the index and the check will not trigger.
To those who do "git add file3" the path and then not modify the
working tree before running "git commit file3", there is no change
to the path in the working tree relative to the index and the check
will not trigger.

Such a change may still bite the people who often start working
incrementally with repeated "edit file2 && git add -p file2" and
then when they are satisfied with the full contents of file2 run
"git commit file2" without an extra "git add file2" to add the last
remaining change in the working tree to the index, though, and we
would need to let people override the check with "--force" or
something to work this extra check around if we were to do so; I do
not offhand know if it is worth it.

Thanks.

```