{"thread":{"id":"37366","subject":"Bug: partially staged file is committed in whole, if there is another staged file","startedAt":"2014-08-17T17:05:46Z","lastAt":"2014-08-17T19:03:26Z","messageCount":2,"participants":["Paul Beckingham","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"247820","messageId":"96FA86FB-D017-470F-899F-EA0F6F28C1E4@beckingham.net","threadId":"37366","inReplyTo":null,"subject":"Bug: partially staged file is committed in whole, if there is another staged file","fromName":"Paul Beckingham","fromEmail":"paul@beckingham.net","sentAt":"2014-08-17T17:05:46Z","receivedAt":"2014-08-17T17:05:46Z","isPatch":false,"sender":{"key":"paul@beckingham.net","avatar":null},"body":"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.\n\nThere is no bug without file1 also being staged.\n\nHere is a transcript illustrating the problem:\n\n$ uname -v\nDarwin Kernel Version 14.0.0: Tue Jul 29 16:22:25 PDT 2014; root:xnu-2782.1.62~4/RELEASE_X86_64\n\n$ git version\ngit version 2.1.0\n\n$ git status -sb\n## master\nM  file1\nMM file2\n$ git commit file2 -m \"adding patch\"\n[master 066a6e2] adding patch\n 1 file changed, 2 insertions(+)\n\n$ git status -sb\n## master\nM  file1\n$\n\n\nRegards,\nPaul"},{"id":"247822","messageId":"xmqq7g27ym4h.fsf@gitster.dls.corp.google.com","threadId":"37366","inReplyTo":"96FA86FB-D017-470F-899F-EA0F6F28C1E4@beckingham.net","subject":"Re: Bug: partially staged file is committed in whole, if there is another staged file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-08-17T19:03:26Z","receivedAt":"2014-08-17T19:03:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paul Beckingham <paul@beckingham.net> writes:\n\n> $ git status -sb\n> ## master\n> M  file1\n> MM file2\n> $ git commit file2 -m \"adding patch\"\n> [master 066a6e2] adding patch\n>  1 file changed, 2 insertions(+)\n>\n> $ git status -sb\n> ## master\n> M  file1\n> $\n\nYou would likely to have seen\n\n    $ git diff --name-only HEAD^ HEAD\n    file2\n\nThis is a very deliberate design decision, and the command is\nworking as expected.  Here is why.\n\nThe filenames (technically, they are not filenames but pathspecs,\ni.e. can be patterns to match the filenames) on the command line of\n\"git commit\" are used to first \"git add\" them internally to form the\ntree used for the next commit, and are not used to limit the paths\nwith changes that are already in the index.\n\nI am not opposed to adding a new mode to use pathspecs to limit the\npaths to be committed from the index without consulting the working\ntree at all, but unless this is explicitly done as a new mode, you\nwould end up forcing people to say\n\n    $ edit file3 file4\n    $ git add file3\n    $ git commit file3\n\nwhile all existing users have been expecting that after modifying a\nfile \"file3\" and commit the changes to that file (and to no other\nfiles), they can say\n\n    $ edit file3 file4\n    $ git commit file3\n\nwithout the extra step of adding it.\n\nWe could however add a check to detect the case where your pathspec\nmatches a path that has changes both in the index and in the working\ntree, and error it out.  To those who never use \"git add\", there is\nno change to the path in the index and the check will not trigger.\nTo those who do \"git add file3\" the path and then not modify the\nworking tree before running \"git commit file3\", there is no change\nto the path in the working tree relative to the index and the check\nwill not trigger.\n\nSuch a change may still bite the people who often start working\nincrementally with repeated \"edit file2 && git add -p file2\" and\nthen when they are satisfied with the full contents of file2 run\n\"git commit file2\" without an extra \"git add file2\" to add the last\nremaining change in the working tree to the index, though, and we\nwould need to let people override the check with \"--force\" or\nsomething to work this extra check around if we were to do so; I do\nnot offhand know if it is worth it.\n\nThanks.\n"}]}