{"thread":{"id":"44547","subject":"[feature request] Make \"commit --only\" work with new files","startedAt":"2016-11-25T17:49:34Z","lastAt":"2016-11-28T17:53:59Z","messageCount":3,"participants":["Luis Ressel","Johannes Schindelin","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"306438","messageId":"20161125175619.19e13e59@gentp.lnet","threadId":"44547","inReplyTo":null,"subject":"[feature request] Make \"commit --only\" work with new files","fromName":"Luis Ressel","fromEmail":"aranea@aixah.de","sentAt":"2016-11-25T16:56:19Z","receivedAt":"2016-11-25T17:49:34Z","isPatch":false,"sender":{"key":"aranea@aixah.de","avatar":"https://avatars.githubusercontent.com/u/864193?v=4"},"body":"Hello,\n\ncurrently \"git commit --only <file>\" only works if <file> is already\nchecked into the repo, but not with newly created and still untracked\nfiles (builtin/commit.c:list_path() throws the error \"error: pathspec\n'<file>' did not match any file(s) known to git.\")\n\nI don't think this limitation is intented. I've had a look at the\nrelevant part of builtin/commit.c, but unfortunately it wasn't obvious\nto me how to fix this.\n\nRegards,\nLuis Ressel\n"},{"id":"306493","messageId":"alpine.DEB.2.20.1611281505270.117539@virtualbox","threadId":"44547","inReplyTo":"20161125175619.19e13e59@gentp.lnet","subject":"Re: [feature request] Make \"commit --only\" work with new files","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-11-28T14:09:34Z","receivedAt":"2016-11-28T14:09:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Luis,\n\nOn Fri, 25 Nov 2016, Luis Ressel wrote:\n\n> currently \"git commit --only <file>\" only works if <file> is already\n> checked into the repo, but not with newly created and still untracked\n> files (builtin/commit.c:list_path() throws the error \"error: pathspec\n> '<file>' did not match any file(s) known to git.\")\n> \n> I don't think this limitation is intented. I've had a look at the\n> relevant part of builtin/commit.c, but unfortunately it wasn't obvious\n> to me how to fix this.\n\nThe best way to go about it is probably to define the desired behavior\nfirst, in the form of a patch to the test suite. Personally, I would\nextend t/t7509-commit.sh with a new test case.\n\nThen, once you have that test case (that should be marked with\ntest_expect_failure, because it fails for now), you can use a debugger\nsuch as gdb to single-step into the relevant function (I guess\n\"prepare_index()\" is a good candidate) to find out why the files are not\nadded.\n\nFrom there, it should be easier to figure out what to patch, and how.\n\nGood hunting!\nJohannes\n"},{"id":"306502","messageId":"xmqqzikjjxtx.fsf@gitster.mtv.corp.google.com","threadId":"44547","inReplyTo":"20161125175619.19e13e59@gentp.lnet","subject":"Re: [feature request] Make \"commit --only\" work with new files","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-11-28T17:52:58Z","receivedAt":"2016-11-28T17:53:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luis Ressel <aranea@aixah.de> writes:\n\n> currently \"git commit --only <file>\" only works if <file> is already\n> checked into the repo, but not with newly created and still untracked\n> files (builtin/commit.c:list_path() throws the error \"error: pathspec\n> '<file>' did not match any file(s) known to git.\")\n\nThe fact that pathspec on the command line of \"commit\" does not let\nyou add new files is true with or without \"--only\".  Yes, \"--only\"\nis the default so with or without it it means the same thing, but\neven with \"--include\" that says \"I am happy with what is in the\nindex, but please take further changes to these paths, too\" does not\naffect files that are not so far tracked.\n\n> I don't think this limitation is intented. \n\nThis actually was intended.  Back when \"commit [--opts] <pathspec>\"\nwas invented, out tools were designed to avoid adding unwanted files\nby mistake (e.g. \"update-index\" without an explicit \"--add\" work\nonly on paths already known to Git), and the behaviour is in line\nwith that design.  It partly was because back then we didn't even\nhave \".gitignore\" mechanism, I would say.  So it was not only\nintended, but was a sensible design decision back then.\n\nI suspect that an argument could be made that it is about time we\nshift the design philosophy and allow adding new paths with pathspec\ngiven to \"git commit\".  If I were designing Git without any existing\nusers, with all the other goodies we already have, and \"git commit\"\nin my version of Git lacked pathspec support now, I might allow it\nto add untracked files with the pathspec [*1*].\n\nThere however are backward compatibility worries.  People who are\nused to the designed behaviour for the past 10 years still expect\nand rely on that\n\n    $ git commit <path-to-dir>\n\nto take _only_ changes to the files that are already tracked in the\n<path-to-dir> since the last \"git add\" they did to them, and other\nfiles in the same <path-to-dir> that are not yet ready (and they\ndeliberately left un-added) will not be in the commit.\n\n\n[Footnote]\n\n*1* I might decide not to, after thinking long enough, though. The\n    point is that times changed and the trade off between safetly of\n    not adding at the point of commit and convenience of adding has\n    shifted. I haven't thought enough to decide that the shift is\n    big enough to warrant the change in behaviour, but at least it\n    is now worth considering.\n\n"}]}