{"thread":{"id":"32672","subject":"[RFC] git rm -u","startedAt":"2013-01-19T21:35:18Z","lastAt":"2013-02-25T19:47:14Z","messageCount":53,"participants":["Eric James Michael Ritz","Tomas Carnecky","Jonathan Nieder","Antoine Pelisse","Matthieu Moy","Junio C Hamano","Martin von Zweigbergk","Piotr Krukowiecki","Robin Rosenberg","Duy Nguyen","Michael J Gruber"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"207274","messageId":"50FB1196.2090309@gmail.com","threadId":"32672","inReplyTo":null,"subject":"[RFC] git rm -u","fromName":"Eric James Michael Ritz","fromEmail":"lobbyjones@gmail.com","sentAt":"2013-01-19T21:35:18Z","receivedAt":"2013-01-19T21:35:18Z","isPatch":false,"sender":{"key":"lobbyjones@gmail.com","avatar":"https://gravatar.com/avatar/22ecfb382789a74b4ef4bfb58551fb9643ab3a161df549ab8653883b19906b61?d=mp&s=160"},"body":"Hello everyone,\n\nI am thinking about implementing a feature but I would appreciate any\nfeedback before I begin, because more experienced Git developers and\nusers may see some major problem that I do not.\n\nEarlier today I deleted a file from a repository. I deleted it\nnormally, not by using `git rm`. So when I looked at `git status` on\nmy terminal it told me about the file no longer being there. In my\nsleepy state of mind I ran `git rm -u` without thinking about. I did\nthis because I have a habit of using `git add -u`. I know `git rm`\ndoes not support that option, but I tried it anyways without thinking\nabout it.\n\nWhen I came to my senses and realized that does not work I began to\nwonder if `git rm -u` should exist. If any deleted, tracked files are\nnot part of the index to commit then `git rm -u` would add that change\nto the index. This would save users the effort of having to type out\n`git rm `, and could be useful when a user is deleting\nmultiple files.\n\nDoes this sound like a reasonable, useful feature to Git? Or is there\nalready a way to accomplish this which I have missed out of ignorance?\nAny thoughts and feedback would be greatly appreciated.\n\n--\nejmr\n南無妙法蓮華經\n"},{"id":"207275","messageId":"1358632037-ner-2564@calvin","threadId":"32672","inReplyTo":"50FB1196.2090309@gmail.com","subject":"Re: [RFC] git rm -u","fromName":"Tomas Carnecky","fromEmail":"tomas.carnecky@gmail.com","sentAt":"2013-01-19T21:47:17Z","receivedAt":"2013-01-19T21:47:17Z","isPatch":false,"sender":{"key":"tomas.carnecky@gmail.com","avatar":null},"body":"On Sat, 19 Jan 2013 16:35:18 -0500, Eric James Michael Ritz wrote:\n> Hello everyone,\n> \n> I am thinking about implementing a feature but I would appreciate any\n> feedback before I begin, because more experienced Git developers and\n> users may see some major problem that I do not.\n> \n> Earlier today I deleted a file from a repository. I deleted it\n> normally, not by using `git rm`. So when I looked at `git status` on\n> my terminal it told me about the file no longer being there. In my\n> sleepy state of mind I ran `git rm -u` without thinking about. I did\n> this because I have a habit of using `git add -u`. I know `git rm`\n> does not support that option, but I tried it anyways without thinking\n> about it.\n> \n> When I came to my senses and realized that does not work I began to\n> wonder if `git rm -u` should exist. If any deleted, tracked files are\n> not part of the index to commit then `git rm -u` would add that change\n> to the index. This would save users the effort of having to type out\n> `git rm `, and could be useful when a user is deleting\n> multiple files.\n> \n> Does this sound like a reasonable, useful feature to Git? Or is there\n> already a way to accomplish this which I have missed out of ignorance?\n> Any thoughts and feedback would be greatly appreciated.\n\nDoes `git add -A` do what you want?\n"},{"id":"207276","messageId":"20130119214921.GE4009@elie.Belkin","threadId":"32672","inReplyTo":"50FB1196.2090309@gmail.com","subject":"Re: [RFC] git rm -u","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-01-19T21:49:22Z","receivedAt":"2013-01-19T21:49:22Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Eric James Michael Ritz wrote:\n\n> When I came to my senses and realized that does not work I began to\n> wonder if `git rm -u` should exist. If any deleted, tracked files are\n> not part of the index to commit then `git rm -u` would add that change\n> to the index.\n\nI like it. If you have time to write such a patch, I'll be happy to\nread it.\n\nThanks,\nJonathan\n"},{"id":"207277","messageId":"CALWbr2zhxkZEGWc5iN-8MivzV7viEdfwV_Q-iH0xSUWkwnSmyQ@mail.gmail.com","threadId":"32672","inReplyTo":"1358632037-ner-2564@calvin","subject":"Re: [RFC] git rm -u","fromName":"Antoine Pelisse","fromEmail":"apelisse@gmail.com","sentAt":"2013-01-19T21:49:56Z","receivedAt":"2013-01-19T21:49:56Z","isPatch":false,"sender":{"key":"apelisse@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1929644?v=4"},"body":"I think `git add -u` would be closer. It would stage removal of files,\nbut would not stage untracked files.\nIt would stage other type of changes though.\n\nOn Sat, Jan 19, 2013 at 10:47 PM, Tomas Carnecky\n wrote:\n> On Sat, 19 Jan 2013 16:35:18 -0500, Eric James Michael Ritz wrote:\n>> Hello everyone,\n>>\n>> I am thinking about implementing a feature but I would appreciate any\n>> feedback before I begin, because more experienced Git developers and\n>> users may see some major problem that I do not.\n>>\n>> Earlier today I deleted a file from a repository. I deleted it\n>> normally, not by using `git rm`. So when I looked at `git status` on\n>> my terminal it told me about the file no longer being there. In my\n>> sleepy state of mind I ran `git rm -u` without thinking about. I did\n>> this because I have a habit of using `git add -u`. I know `git rm`\n>> does not support that option, but I tried it anyways without thinking\n>> about it.\n>>\n>> When I came to my senses and realized that does not work I began to\n>> wonder if `git rm -u` should exist. If any deleted, tracked files are\n>> not part of the index to commit then `git rm -u` would add that change\n>> to the index. This would save users the effort of having to type out\n>> `git rm `, and could be useful when a user is deleting\n>> multiple files.\n>>\n>> Does this sound like a reasonable, useful feature to Git? Or is there\n>> already a way to accomplish this which I have missed out of ignorance?\n>> Any thoughts and feedback would be greatly appreciated.\n>\n> Does `git add -A` do what you want?\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"207278","messageId":"50FB1673.8020808@gmail.com","threadId":"32672","inReplyTo":"CALWbr2zhxkZEGWc5iN-8MivzV7viEdfwV_Q-iH0xSUWkwnSmyQ@mail.gmail.com","subject":"Re: [RFC] git rm -u","fromName":"Eric James Michael Ritz","fromEmail":"lobbyjones@gmail.com","sentAt":"2013-01-19T21:56:03Z","receivedAt":"2013-01-19T21:56:03Z","isPatch":false,"sender":{"key":"lobbyjones@gmail.com","avatar":"https://gravatar.com/avatar/22ecfb382789a74b4ef4bfb58551fb9643ab3a161df549ab8653883b19906b61?d=mp&s=160"},"body":"On 01/19/2013 04:49 PM, Antoine Pelisse wrote:\n > I think `git add -u` would be closer. It would stage removal of\n > files, but would not stage untracked files. It would stage other\n > type of changes though.\n\nOn Sat, Jan 19, 2013 at 10:47 PM, Tomas Carnecky\n > Does `git add -A` do what you want?\n\nThank you Tomas and Antoine. Both of these commands do what I want:\nstage deleted files on the index. But does the idea of a `git rm -u`\nstill sound useful since these commands also stage changes besides\ndeleted files?\n\n--\nejmr\n南無妙法蓮華經\n"},{"id":"207279","messageId":"50FB179D.7010006@gmail.com","threadId":"32672","inReplyTo":"20130119214921.GE4009@elie.Belkin","subject":"Re: [RFC] git rm -u","fromName":"Eric James Michael Ritz","fromEmail":"lobbyjones@gmail.com","sentAt":"2013-01-19T22:01:01Z","receivedAt":"2013-01-19T22:01:01Z","isPatch":false,"sender":{"key":"lobbyjones@gmail.com","avatar":"https://gravatar.com/avatar/22ecfb382789a74b4ef4bfb58551fb9643ab3a161df549ab8653883b19906b61?d=mp&s=160"},"body":"On 01/19/2013 04:49 PM, Jonathan Nieder wrote:\n > Eric James Michael Ritz wrote:\n >\n >> When I came to my senses and realized that does not work I began to\n >> wonder if `git rm -u` should exist. If any deleted, tracked files\n >> are not part of the index to commit then `git rm -u` would add that\n >> change to the index.\n >\n > I like it. If you have time to write such a patch, I'll be happy to\n > read it.\n\nThank you for the offer Jonathan. I must go ahead and apologize for\nmy rusty ability with C; I haven’t needed to use the language in\nyears. But I will familiarize myself with the Git source and try to\nput a patch (or series of patches) together over the next week or two.\n\n--\nejmr\n南無妙法蓮華經\n"},{"id":"207292","messageId":"vpq622s9jk1.fsf@grenoble-inp.fr","threadId":"32672","inReplyTo":"20130119214921.GE4009@elie.Belkin","subject":"Re: [RFC] git rm -u","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-01-20T11:32:14Z","receivedAt":"2013-01-20T11:32:14Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jonathan Nieder writes:\n\n> Eric James Michael Ritz wrote:\n>\n>> When I came to my senses and realized that does not work I began to\n>> wonder if `git rm -u` should exist. If any deleted, tracked files are\n>> not part of the index to commit then `git rm -u` would add that change\n>> to the index.\n>\n> I like it. If you have time to write such a patch, I'll be happy to\n> read it.\n\nI can leave with \"git add -u\", but a \"git rm -u\" that would only look at\ndeletions, and not stage existing files changes would make sense.\n\nOne thing to be careful about is what to do when the command is called\nfrom a subdirectory. In general, Git commands use this convention:\n\n* git foo => tree-wide command\n* git foo . => restrict to current directory\n\n\"git add -u\" is one of the only exceptions (with \"git grep\"). I consider\nthis as a bug, and think this should be changed. This has been discussed\nseveral times here, but no one took the time to actually do the change\n(changing is easy, but having a correct migration plan wrt backward\ncompatibility is not).\n\nImplementing \"git rm -u\" as a tree-wide command would create a\ndiscrepancy with \"git add -u\". Implementing it as a \"current directory\"\ncommand would make the migration harder if we eventually try to change\n\"git add -u\". Perhaps \"git rm -u\" should be forbidden from a\nsubdirectory (with an error message pointing to \"git rm -u :/\" and \"git\nrm -u .\"), waiting for a possible \"git add -u\" change.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"207314","messageId":"7v622rn1bh.fsf@alter.siamese.dyndns.org","threadId":"32672","inReplyTo":"vpq622s9jk1.fsf@grenoble-inp.fr","subject":"Re: [RFC] git rm -u","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-20T18:42:26Z","receivedAt":"2013-01-20T18:42:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> \"git add -u\" is one of the only exceptions (with \"git grep\"). I consider\n> this as a bug, and think this should be changed. This has been discussed\n> several times here, but no one took the time to actually do the change\n\nDid we ever agree that it is a good change to begin with? Pointers?\n"},{"id":"207315","messageId":"7v1udfn0tm.fsf@alter.siamese.dyndns.org","threadId":"32672","inReplyTo":"vpq622s9jk1.fsf@grenoble-inp.fr","subject":"Re: [RFC] git rm -u","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-20T18:53:09Z","receivedAt":"2013-01-20T18:53:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Implementing \"git rm -u\" as a tree-wide command would create a\n> discrepancy with \"git add -u\". Implementing it as a \"current directory\"\n> command would make the migration harder if we eventually try to change\n> \"git add -u\". Perhaps \"git rm -u\" should be forbidden from a\n> subdirectory (with an error message pointing to \"git rm -u :/\" and \"git\n> rm -u .\"), waiting for a possible \"git add -u\" change.\n\nYeah, that sounds sensible. Start with a \"'git rm -u' is forbidden\nwithout arguments\", give advise to use either \".\" or \":/\". And stop\nthere.\n\nThe first step of \"git add -u\" migration plan would be to warn when\nno argument is given and update all the existing index entries, and\ngive the same advise to use either \".\" or \":/\". Keep this for three\ncycles: 3 * (8 to 10 weeks per cycle) = 27 weeks ~ 1/2 year.\n\nThe second step would be to forbid \"git add -u\", and keep the\nadvise. That will make it in-line with \"git rm -u\".\n"},{"id":"207322","messageId":"50FC43D1.6080701@gmail.com","threadId":"32672","inReplyTo":"7v1udfn0tm.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] git rm -u","fromName":"Eric James Michael Ritz","fromEmail":"lobbyjones@gmail.com","sentAt":"2013-01-20T19:21:53Z","receivedAt":"2013-01-20T19:21:53Z","isPatch":false,"sender":{"key":"lobbyjones@gmail.com","avatar":"https://gravatar.com/avatar/22ecfb382789a74b4ef4bfb58551fb9643ab3a161df549ab8653883b19906b61?d=mp&s=160"},"body":"On 01/20/2013 01:53 PM, Junio C Hamano wrote:\n > Matthieu Moy writes:\n >\n >> Implementing \"git rm -u\" as a tree-wide command would create a\n >> discrepancy with \"git add -u\". Implementing it as a \"current\n >> directory\" command would make the migration harder if we eventually\n >> try to change \"git add -u\". Perhaps \"git rm -u\" should be forbidden\n >> from a subdirectory (with an error message pointing to \"git rm -u\n >> :/\" and \"git rm -u .\"), waiting for a possible \"git add -u\" change.\n >\n > Yeah, that sounds sensible. Start with a \"'git rm -u' is forbidden\n > without arguments\", give advise to use either \".\" or \":/\". And stop\n > there.\n\nI was unaware of any plan to change `git add -u`, but the above makes\nsense to me. I will use those suggestions as guidelines for the\ninitial implementation of `git rm -u`. In particular, it will require\nan argument like `.` or `:/`. It sounds like the future direction of\n`git add -u` will play a role in how `git rm -u` should behave so that\nthere is consistency between the two, so I will try to take a\nconservative approach in my implementation. Thank you both for the\nadvice and insight.\n\n--\nejmr\n南無妙法蓮華經\n"},{"id":"207338","messageId":"7vobgjk0iw.fsf@alter.siamese.dyndns.org","threadId":"32672","inReplyTo":"7v622rn1bh.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] git rm -u","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-20T21:27:51Z","receivedAt":"2013-01-20T21:27:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Matthieu Moy writes:\n>\n>> \"git add -u\" is one of the only exceptions (with \"git grep\"). I consider\n>> this as a bug, and think this should be changed. This has been discussed\n>> several times here, but no one took the time to actually do the change\n>\n> Did we ever agree that it is a good change to begin with? Pointers?\n\nI think you can guess but I no longer need pointers. Others may\nstill be helped, though.\n\nThe argument IIRC boils down to\n\n - \"git add -u\" was made a whole-tree operation when there weren't\n the \":/\" magic pathspec, but \"add -u\" is very often something you\n want to do whole tree, and \"(cd ../../..; git add -u)\" or \"git\n add -u ../../..\" are too cumbersome to type.\n\n - \"git add -u .\" to limit it to the current directory is easy to\n type.\n\n - As we have the \"from the root\" magic pathspec these days,\n requiring \"git add -u :/\" when the user really means to add\n everything is no longer too much of a burden, but if we suddenly\n changed \"git add -u\" to mean \"git add -u .\", that is too much of\n a change in the semantics.\n"},{"id":"207341","messageId":"CANiSa6gTOFkDA_Cuu3BrHDNE17z8qukB7h9OMvP8OVjy2ej04Q@mail.gmail.com","threadId":"32672","inReplyTo":"7vobgjk0iw.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] git rm -u","fromName":"Martin von Zweigbergk","fromEmail":"martinvonz@gmail.com","sentAt":"2013-01-20T22:17:09Z","receivedAt":"2013-01-20T22:17:09Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Sun, Jan 20, 2013 at 1:27 PM, Junio C Hamano wrote:\n> Junio C Hamano writes:\n>\n>> Matthieu Moy writes:\n>>\n>>> \"git add -u\" is one of the only exceptions (with \"git grep\"). I consider\n>>> this as a bug, and think this should be changed. This has been discussed\n>>> several times here, but no one took the time to actually do the change\n>\n> - As we have the \"from the root\" magic pathspec these days,\n> requiring \"git add -u :/\" when the user really means to add\n> everything is no longer too much of a burden, but if we suddenly\n> changed \"git add -u\" to mean \"git add -u .\", that is too much of\n> a change in the semantics.\n\nAnd I think someone (Jeff?) pointed out that that last part is even\nmore true for \"git clean\", which also currently works on the current\ndirectory if not told otherwise.\n"},{"id":"207369","messageId":"CAA01Csrv26WrrJDAo-1cr+rW6rYFGQZpYgtafEh=Wgtzswdv_g@mail.gmail.com","threadId":"32672","inReplyTo":"7v1udfn0tm.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] git rm -u","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki@gmail.com","sentAt":"2013-01-21T08:09:42Z","receivedAt":"2013-01-21T08:09:42Z","isPatch":false,"sender":{"key":"piotr.krukowiecki@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3259959?v=4"},"body":"On Sun, Jan 20, 2013 at 7:53 PM, Junio C Hamano wrote:\n> Matthieu Moy writes:\n>\n>> Implementing \"git rm -u\" as a tree-wide command would create a\n>> discrepancy with \"git add -u\". Implementing it as a \"current directory\"\n>> command would make the migration harder if we eventually try to change\n>> \"git add -u\". Perhaps \"git rm -u\" should be forbidden from a\n>> subdirectory (with an error message pointing to \"git rm -u :/\" and \"git\n>> rm -u .\"), waiting for a possible \"git add -u\" change.\n>\n> Yeah, that sounds sensible. Start with a \"'git rm -u' is forbidden\n> without arguments\", give advise to use either \".\" or \":/\". And stop\n> there.\n>\n> The first step of \"git add -u\" migration plan would be to warn when\n> no argument is given and update all the existing index entries, and\n> give the same advise to use either \".\" or \":/\". Keep this for three\n> cycles: 3 * (8 to 10 weeks per cycle) = 27 weeks ~ 1/2 year.\n>\n> The second step would be to forbid \"git add -u\", and keep the\n> advise. That will make it in-line with \"git rm -u\".\n\nDo you mean \"git add\" will be disallowed without \".\" or \":/\" argument?\nOr will this change in future and \"git add\" without argument will me\n\"whole tree\", same as \":/\" ?\n\n--\nPiotr Krukowiecki\n"},{"id":"207372","messageId":"vpqwqv753v1.fsf@grenoble-inp.fr","threadId":"32672","inReplyTo":"CAA01Csrv26WrrJDAo-1cr+rW6rYFGQZpYgtafEh=Wgtzswdv_g@mail.gmail.com","subject":"Re: [RFC] git rm -u","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-01-21T08:37:06Z","receivedAt":"2013-01-21T08:37:06Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Piotr Krukowiecki writes:\n\n> Do you mean \"git add\" will be disallowed without \".\" or \":/\" argument?\n> Or will this change in future and \"git add\" without argument will me\n> \"whole tree\", same as \":/\" ?\n\nLet's talk conditional, not future, for now.\n\nIf the idea is to change the semantics without argument, it has to be\ndone carefully, and implies disallowing the argumentless version for a\nwhile (or some better idea) to avoid confusion.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"207385","messageId":"vpqmww353j6.fsf@grenoble-inp.fr","threadId":"32672","inReplyTo":"7v622rn1bh.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] git rm -u","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-01-21T08:44:13Z","receivedAt":"2013-01-21T08:44:13Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Matthieu Moy writes:\n>\n>> \"git add -u\" is one of the only exceptions (with \"git grep\"). I consider\n>> this as a bug, and think this should be changed. This has been discussed\n>> several times here, but no one took the time to actually do the change\n>\n> Did we ever agree that it is a good change to begin with? Pointers?\n\nI don't think a consensus was reached, but it has been discussed at\nleast once in this thread:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/166223/focus=168238\n\nEssentially, the discussion boiled down to \"it would be cool to change,\nbut the migration won't be easy\".\n\nThe main argument for change is (for me) consistency. Having\n\"git add -p\" tree-wide and \"git add -u\" limited to . is really strange.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"207386","messageId":"7v622qhouc.fsf@alter.siamese.dyndns.org","threadId":"32672","inReplyTo":"CAA01Csrv26WrrJDAo-1cr+rW6rYFGQZpYgtafEh=Wgtzswdv_g@mail.gmail.com","subject":"Re: [RFC] git rm -u","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-21T09:23:07Z","receivedAt":"2013-01-21T09:23:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Piotr Krukowiecki writes:\n\n> Do you mean \"git add\" will be disallowed without \".\" or \":/\" argument?\n> Or will this change in future and \"git add\" without argument will me\n> \"whole tree\", same as \":/\" ?\n\nNo. This is only about \"git add -u\", not any other forms of\n\"git add ...with or without other args...\".\n\n\"git add -u\" historically meant, and it still means, to\n\"update the index with every change in the working tree\", even when\nyou are in a subdirectory.\n\nBack when \"git add -u\" was invented, we didn't have the \":/\", which\nlets us tell commands that take pathspecs \"I want everything from\nthe top of the working tree.\". If \"git add -u\" limited its\noperation to the current directory, after working everywhere in the\nworking tree, cd'ing around and ending up to be in a subdirectory\nsomwhere deep, you had to \"cd ../../.. && git add -u\", which was\ncumbersome. If \"git add -u\" always meant the whole tree, limiting\nit to the current directory with \"git add -u .\" was easy,\nand that is why the default was chosen to the \"whole tree\".\n\nBecause we have \":/\" these days, changing something that limits its\naction to the current directory by default to instead work on the\nwhole tree no longer makes much sense. That is, if we _were_ to\nchange \"git add -u\", it would be in the opposite direction,\ni.e. to update the index only with the paths below the current\ndirectory.\n\nSuch a change has to be done carefully. Existing users do expect\nthe current behaviour, so we have to first _break_ their fingers and\nhabits and train them to say \"add -u :/\" when they mean the whole\ntree operation. Silently accepting \"add -u\" and changing its\nmeaning to update the index only with the paths below the current\ndirectory will cause them trouble by leaving changes they _thought_\nthey added out of the index, and is an unacceptable change.\n\nThe first step of migration is \"git add -u\" that loudly\nwarns, so that uses of that form in scripts are updated before the\nsecond step to avoid a flag-day breakage and start traing fingers\nand habits of the users.\n\nThe second step is to make \"add -u\" fail, again with a\nmessage that tells users to be explicit and add \":/\" or \".\" at the\nend if they mean \"the whole tree\" or \"the current directory\".\n\nAfter keeping Git in that secnd step for sufficiently long time to\ntrain users to type \":/\" or \".\" explicitly, we can then finally\nswitch the default of \"git add -u\" to limit it to the\ncurrent directory, instead of failing the command.\n"},{"id":"207392","messageId":"1358769611-3625-1-git-send-email-Matthieu.Moy@imag.fr","threadId":"32672","inReplyTo":"7v1udfn0tm.fsf@alter.siamese.dyndns.org","subject":"[RFC/PATCH] add: warn when -u or -A is used without filepattern","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2013-01-21T12:00:11Z","receivedAt":"2013-01-21T12:00:11Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Most git commands that can be used with our without a filepattern are\ntree-wide by default, the filepattern being used to restrict their scope.\nA few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'.\n\nThe inconsistancy of 'git add -u' and 'git add -A' are particularly\nproblematic since other 'git add' subcommands (namely 'git add -p' and\n'git add -e') are tree-wide by default.\n\nFlipping the default now is unacceptable, so this patch starts training\nusers to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare\nfor the next steps:\n\n* forbid 'git add -u|-A' without filepattern (like 'git add' without\n option)\n\n* much later, maybe, re-allow 'git add -u|-A' without filepattern, with a\n tree-wide scope.\n\nA nice side effect of this patch is that it makes the :/ special\nfilepattern easier to discover for users.\n\nSigned-off-by: Matthieu Moy \n---\nJunio C Hamano writes:\n\n> The first step of \"git add -u\" migration plan would be to warn when\n> no argument is given and update all the existing index entries, and\n> give the same advise to use either \".\" or \":/\". Keep this for three\n> cycles: 3 * (8 to 10 weeks per cycle) = 27 weeks ~ 1/2 year.\n\nThe first step should look like this patch. The message remains vague\nabout the next steps (\"change in a future Git version\", no mention of\nthe exact change nor of the exact version in which it will happen),\nbut I'm fine with refining it (perhaps this could be a 2.0 change,\nlike the change to push.default?).\n\n Documentation/git-add.txt | 7 ++++---\n builtin/add.c | 30 +++++++++++++++++++++++++++++-\n 2 files changed, 33 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-add.txt b/Documentation/git-add.txt\nindex fd9e36b..5333559 100644\n--- a/Documentation/git-add.txt\n+++ b/Documentation/git-add.txt\n@@ -107,9 +107,10 @@ apply to the index. See EDITING PATCHES below.\n \tfrom the index if the corresponding files in the working tree\n \thave been removed.\n +\n-If no is given, default to \".\"; in other words,\n-update all tracked files in the current directory and its\n-subdirectories.\n+If no is given, the current version of Git defaults to\n+\".\"; in other words, update all tracked files in the current directory\n+and its subdirectories. This default will change in a future version\n+of Git, hence the form without should not be used.\n \n -A::\n --all::\ndiff --git a/builtin/add.c b/builtin/add.c\nindex e664100..e6eb829 100644\n--- a/builtin/add.c\n+++ b/builtin/add.c\n@@ -373,6 +373,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \tint add_new_files;\n \tint require_pathspec;\n \tchar *seen = NULL;\n+\tconst char *option_with_implicit_dot = NULL;\n \n \tgit_config(add_config, NULL);\n \n@@ -392,7 +393,34 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \t\tdie(_(\"-A and -u are mutually incompatible\"));\n \tif (!show_only && ignore_missing)\n \t\tdie(_(\"Option --ignore-missing can only be used together with --dry-run\"));\n-\tif ((addremove || take_worktree_changes) && !argc) {\n+\tif (addremove)\n+\t\toption_with_implicit_dot = \"--all\";\n+\tif (take_worktree_changes)\n+\t\toption_with_implicit_dot = \"--update\";\n+\tif (option_with_implicit_dot && !argc) {\n+\t\t/*\n+\t\t * To be consistant with \"git add -p\" and most Git\n+\t\t * commands, we should default to being tree-wide, but\n+\t\t * this is not the original behavior and can't be\n+\t\t * changed until users trained themselves not to type\n+\t\t * \"git add -u\" or \"git add -A\". For now, we warn and\n+\t\t * keep the old behavior. Later, this warning can be\n+\t\t * turned into a die(...), and eventually we may\n+\t\t * reallow the command with a new behavior.\n+\t\t */\n+\t\twarning(_(\"The behavior of 'git add %s' with no path argument will change in a future\\n\"\n+\t\t\t \"Git version and shouldn't be used anymore. To add content for the whole tree, run:\\n\"\n+\t\t\t \"\\n\"\n+\t\t\t \" git add %s :/\\n\"\n+\t\t\t \"\\n\"\n+\t\t\t \"To restrict the command to the current directory, run:\\n\"\n+\t\t\t \"\\n\"\n+\t\t\t \" git add %s .\\n\"\n+\t\t\t \"\\n\"\n+\t\t\t \"With the current Git version, the command is restricted to the current directory.\"),\n+\t\t\toption_with_implicit_dot,\n+\t\t\toption_with_implicit_dot,\n+\t\t\toption_with_implicit_dot);\n \t\tstatic const char *here[2] = { \".\", NULL };\n \t\targc = 1;\n \t\targv = here;\n-- \n1.8.0.319.g8abfee4\n"},{"id":"207401","messageId":"1217961884.4232967.1358780423428.JavaMail.root@dewire.com","threadId":"32672","inReplyTo":"1358769611-3625-1-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg@dewire.com","sentAt":"2013-01-21T15:00:23Z","receivedAt":"2013-01-21T15:00:23Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"\n\n----- Ursprungligt meddelande -----\n> Most git commands that can be used with our without a filepattern are\n> tree-wide by default, the filepattern being used to restrict their\n> scope.\n> A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git\n> add -A'.\n> \n> The inconsistancy of 'git add -u' and 'git add -A' are particularly\n> problematic since other 'git add' subcommands (namely 'git add -p'\n> and\n> 'git add -e') are tree-wide by default.\n> \n> Flipping the default now is unacceptable, so this patch starts\n> training\n> users to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to\n> prepare\n> for the next steps:\n> \n> * forbid 'git add -u|-A' without filepattern (like 'git add' without\n> option)\n\ngit add -u without filepattern is, I believe very common, so no noisy\noutput there please.\n\ngit diff\n#looks good\ngit add -u\n\n-- robin\n"},{"id":"207402","messageId":"vpqy5fmva6b.fsf@grenoble-inp.fr","threadId":"32672","inReplyTo":"1217961884.4232967.1358780423428.JavaMail.root@dewire.com","subject":"Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-01-21T15:16:12Z","receivedAt":"2013-01-21T15:16:12Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Robin Rosenberg writes:\n\n> git add -u without filepattern is, I believe very common, so no noisy\n> output there please.\n\nWhat are you exactly suggesting? That we keep the inconsistant semantics\nof \"git add -u\" or \"git add -A\"? Or another migration plan?\n\n> git diff\n> #looks good\n> git add -u\n\nThat's indeed the kind of mistake I'd like to avoid. In your example,\n\"git diff\" is tree-wide, and \"git add -u\" is limited to ., so in general\n\"git add -u\" won't stage the same thing as \"git diff\" just showed.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"207419","messageId":"7v1udegy2o.fsf@alter.siamese.dyndns.org","threadId":"32672","inReplyTo":"7v622qhouc.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] git rm -u","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-21T19:01:19Z","receivedAt":"2013-01-21T19:01:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Piotr Krukowiecki writes:\n>\n>> Do you mean \"git add\" will be disallowed without \".\" or \":/\" argument?\n>> Or will this change in future and \"git add\" without argument will me\n>> \"whole tree\", same as \":/\" ?\n>\n> No. This is only about \"git add -u\", not any other forms of\n> \"git add ...with or without other args...\".\n\nThis part is still correct, but all the remainder of the message I\nam responding to is a total garbage, written from faulty memory\nwithout fact check. Sorry about noise.\n\n> \"git add -u\" historically meant,...\n\nThe very original \"git add -u\" done at v1.5.2-rc0~17^2\n(git-add -u: match the index with working tree., 2007-04-20) did\nupdate the index with every change under the root of the working\ntree, no matter where you were.\n\nBut v1.5.2.5~1 (git-add -u paths... now works from subdirectory,\n2007-08-16) changed the semantics to limit the operation to the\nworking tree. The log message seems to suggest that this was a\ndeliberate semantics change post release (i.e. the \"tree-wide\" was a\nbug); I do not recall if there was a discussion and concensus when\nthis change was made, though.\n"},{"id":"207422","messageId":"CAA01Csp3S17+RyD15mRwfzbY2TTf27m14dpS7CkL5KSg6cWStg@mail.gmail.com","threadId":"32672","inReplyTo":"7v622qhouc.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] git rm -u","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki@gmail.com","sentAt":"2013-01-21T19:10:14Z","receivedAt":"2013-01-21T19:10:14Z","isPatch":false,"sender":{"key":"piotr.krukowiecki@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3259959?v=4"},"body":"On Mon, Jan 21, 2013 at 10:23 AM, Junio C Hamano wrote:\n> No. This is only about \"git add -u\", not any other forms of\n> \"git add ...with or without other args...\".\n>\n> \"git add -u\" historically meant, and it still means, to\n> \"update the index with every change in the working tree\", even when\n> you are in a subdirectory.\n\nBut it *currently* limits itself to a subdirectory - does not work on\nwhole tree:\n\npiotr@PIOTR-X73 ~/dv/test/dir1 (master)\n$ git status\n# On branch master\n# Changes not staged for commit:\n# (use \"git add ...\" to update what will be committed)\n# (use \"git checkout -- ...\" to discard changes in working directory)\n#\n# modified: dir2/file2.txt\n# modified: file1.txt\n# modified: ../file.txt\n#\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n\npiotr@PIOTR-X73 ~/dv/test/dir1 (master)\n$ git add -u\n\npiotr@PIOTR-X73 ~/dv/test/dir1 (master)\n$ git status\n# On branch master\n# Changes to be committed:\n# (use \"git reset HEAD ...\" to unstage)\n#\n# modified: dir2/file2.txt\n# modified: file1.txt\n#\n# Changes not staged for commit:\n# (use \"git add ...\" to update what will be committed)\n# (use \"git checkout -- ...\" to discard changes in working directory)\n#\n# modified: ../file.txt\n#\n\npiotr@PIOTR-X73 ~/dv/test/dir1 (master)\n$ git --version\ngit version 1.8.0.msysgit.0\n\n\n\n--\nPiotr Krukowiecki\n"},{"id":"207424","messageId":"7vwqv6fiz7.fsf@alter.siamese.dyndns.org","threadId":"32672","inReplyTo":"1358769611-3625-1-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-21T19:12:44Z","receivedAt":"2013-01-21T19:12:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Most git commands that can be used with our without a filepattern are\n> tree-wide by default, the filepattern being used to restrict their scope.\n> A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'.\n>\n> The inconsistancy of 'git add -u' and 'git add -A' are particularly\n> problematic since other 'git add' subcommands (namely 'git add -p' and\n> 'git add -e') are tree-wide by default.\n>\n> Flipping the default now is unacceptable, so this patch starts training\n> users to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare\n> for the next steps:\n>\n> * forbid 'git add -u|-A' without filepattern (like 'git add' without\n> option)\n>\n> * much later, maybe, re-allow 'git add -u|-A' without filepattern, with a\n> tree-wide scope.\n>\n> A nice side effect of this patch is that it makes the :/ special\n> filepattern easier to discover for users.\n\nNicely explained.\n\n> The first step should look like this patch. The message remains vague\n> about the next steps (\"change in a future Git version\", no mention of\n> the exact change nor of the exact version in which it will happen),\n> but I'm fine with refining it (perhaps this could be a 2.0 change,\n> like the change to push.default?).\n\nI think rolling big changes line these to a single version bump\nwould make sense, if we were to do it.\n\nI have to wonder if \"git add -p\" and \"git add -e\" are the ones that\nare broken, and the migration suggested here is going in the wrong\ndirection, though. After all \"add -p\" and \"add -e\" are interactive\nby their nature, so it is a _lot_ easier to change their default\nbehaviour in the name of \"usability fix\", \"consistency fix\", or\nwhatever. Wouldn't we achieve the same consistency across modes of\n\"add\" if we made them relative to the current directory?\n"},{"id":"207434","messageId":"CAA01CsqwuR+HTUWA+iqSamOcR0WBhwK0kfn5+80L95TZn-SRng@mail.gmail.com","threadId":"32672","inReplyTo":"7vwqv6fiz7.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki@gmail.com","sentAt":"2013-01-21T19:34:35Z","receivedAt":"2013-01-21T19:34:35Z","isPatch":true,"sender":{"key":"piotr.krukowiecki@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3259959?v=4"},"body":"On Mon, Jan 21, 2013 at 8:12 PM, Junio C Hamano wrote:\n> Matthieu Moy writes:\n>\n>> Most git commands that can be used with our without a filepattern are\n>> tree-wide by default, the filepattern being used to restrict their scope.\n>> A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'.\n>>\n>> The inconsistancy of 'git add -u' and 'git add -A' are particularly\n>> problematic since other 'git add' subcommands (namely 'git add -p' and\n>> 'git add -e') are tree-wide by default.\n>>\n>> Flipping the default now is unacceptable, so this patch starts training\n>> users to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare\n>> for the next steps:\n>>\n>> * forbid 'git add -u|-A' without filepattern (like 'git add' without\n>> option)\n>>\n>> * much later, maybe, re-allow 'git add -u|-A' without filepattern, with a\n>> tree-wide scope.\n>>\n>\n> I have to wonder if \"git add -p\" and \"git add -e\" are the ones that\n> are broken, and the migration suggested here is going in the wrong\n> direction, though. After all \"add -p\" and \"add -e\" are interactive\n> by their nature, so it is a _lot_ easier to change their default\n> behaviour in the name of \"usability fix\", \"consistency fix\", or\n> whatever. Wouldn't we achieve the same consistency across modes of\n> \"add\" if we made them relative to the current directory?\n\nConsistency is one issue. +1 for having consistent behavior. But even\nif all \"git add\" modes work consistently on current subdirectory, they\nwill be inconsistent with other git command, for example \"git status\"\nor \"git diff\". I think it'd be better to have all git command work the\nsame (is that possible? is there a list of all commands which work on\ncurrent dir vs those working on whole tree?). I believe changing all\ncommands to work on current subdir is not an option.\n\nAnother issue is usability. Can we definitely say which is better: add\nall changes from current subdir, or add all changes from whole tree? I\ndon't know. At the moment I think whole tree is better. That's usually\nwhat I want. If I want to add only some changes, I first list the\nstatus or run diff, and then explicitly say what to add. OTOH \"add\" is\nkind of dangerous command - adding content to index is not reversible\n(i.e. if there already is a previous version in index with changes,\n\"add\" will overwrite it). But at the same time, another \"dangerous\"\ncommand, \"git add -a\" works on whole tree. I use it frequently and\nnever had any problem with it.\n\nSo, from me +1 on making all commands work on whole tree.\n\n--\nPiotr Krukowiecki\n"},{"id":"207437","messageId":"vpqhamapal1.fsf@grenoble-inp.fr","threadId":"32672","inReplyTo":"7v1udegy2o.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] git rm -u","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-01-21T20:03:54Z","receivedAt":"2013-01-21T20:03:54Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> But v1.5.2.5~1 (git-add -u paths... now works from subdirectory,\n> 2007-08-16) changed the semantics to limit the operation to the\n> working tree.\n\nNot really. It fixed \"git add -u path\", not plain \"git add -u\". A quick\ntest checking out and compiling v1.5.2.5~1^ shows that \"git add -u .\"\nfrom a subdirectory was adding everything from the root.\n\nMy interpretation is that v1.5.2.5~1 fixed an actual bug, without\nthinking about what would happen when \"git add -u\" was called without\npath, so the behavior is \"what happens to be the most natural to\nimplement\". Indeed, the behavior was actually documented only later, in\nv1.5.4.3~3 (Feb 21 00:29:39 2008, Clarified the meaning of git-add -u in\nthe documentation), the previous doc said only \"If no paths are\nspecified, all tracked files are updated.\".\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"207438","messageId":"vpqbocipaha.fsf@grenoble-inp.fr","threadId":"32672","inReplyTo":"CAA01CsqwuR+HTUWA+iqSamOcR0WBhwK0kfn5+80L95TZn-SRng@mail.gmail.com","subject":"Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-01-21T20:06:09Z","receivedAt":"2013-01-21T20:06:09Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Piotr Krukowiecki writes:\n\n> Another issue is usability. Can we definitely say which is better: add\n> all changes from current subdir, or add all changes from whole tree? I\n> don't know.\n\nHard to tell, depending on users, use-case, ...\n\nBut the good news is: whatever option is chosen, the other one is only a\nfew keystrokes away (git add -u . or git add -u :/).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"207440","messageId":"vpqzk02nvp0.fsf@grenoble-inp.fr","threadId":"32672","inReplyTo":"7vwqv6fiz7.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-01-21T20:10:51Z","receivedAt":"2013-01-21T20:10:51Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Wouldn't we achieve the same consistency across modes of\n> \"add\" if we made them relative to the current directory?\n\nAs other people already said, it would be nice to have consistency\naccross most if not all commands. AFAICT, the only exceptions to\n\"tree-wide by default, say '.' to restrict to subdirectory\" are git add\n-u|-A, git grep and git clean.\n\nArguably, the \"subtree by default\" is a safety feature of \"git clean\",\nand should be kept.\n\nI don't care too deepely about \"git grep\". From previous discussions,\nIIRC, other people didn't care either.\n\nOn the other hand, I can think of at least \"git log\", \"git diff\", \"git\nstatus\" and to some extend \"git commit\" as tree-wide by default with\noptional path restriction. I'd like \"git add\" to be on the same side.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"207442","messageId":"2025469478.4311560.1358800186770.JavaMail.root@dewire.com","threadId":"32672","inReplyTo":"vpqy5fmva6b.fsf@grenoble-inp.fr","subject":"Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg@dewire.com","sentAt":"2013-01-21T20:29:46Z","receivedAt":"2013-01-21T20:29:46Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"\n\n----- Ursprungligt meddelande -----\n\n> > git diff\n> > #looks good\n> > git add -u\n> \n> That's indeed the kind of mistake I'd like to avoid. In your example,\n> \"git diff\" is tree-wide, and \"git add -u\" is limited to ., so in\n> general\n> \"git add -u\" won't stage the same thing as \"git diff\" just showed.\n\nGood point. I rarely cd to anything but the top of the tree, but that\nmight be just me. OTOH, git diff after -u would remind me. It would bad if -u \nwas tree wide and diff wasn't, but fortunately that's not the case.\n\nThe -A is a bit worse since it adds all the crap files lying around.\n\n-- robin\n"},{"id":"207445","messageId":"20130121222248.GA3586@elie.Belkin","threadId":"32672","inReplyTo":"1358769611-3625-1-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-01-21T22:22:49Z","receivedAt":"2013-01-21T22:22:49Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nMatthieu Moy wrote:\n\n> The inconsistancy of 'git add -u' and 'git add -A' are particularly\n> problematic since other 'git add' subcommands (namely 'git add -p' and\n> 'git add -e') are tree-wide by default.\n>\n> Flipping the default now is unacceptable, so this patch starts training\n> users to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare\n> for the next steps:\n\nThanks for tackling this.\n\n> --- a/builtin/add.c\n> +++ b/builtin/add.c\n[...]\n> +\tif (option_with_implicit_dot && !argc) {\n> +\t\t/*\n> +\t\t * To be consistant with \"git add -p\" and most Git\n> +\t\t * commands, we should default to being tree-wide, but\n> +\t\t * this is not the original behavior and can't be\n> +\t\t * changed until users trained themselves not to type\n> +\t\t * \"git add -u\" or \"git add -A\". For now, we warn and\n> +\t\t * keep the old behavior. Later, this warning can be\n> +\t\t * turned into a die(...), and eventually we may\n> +\t\t * reallow the command with a new behavior.\n> +\t\t */\n> +\t\twarning(_(\"The behavior of 'git add %s' with no path argument will change in a future\\n\"\n\nWould it be possible to make this conditional on cwd not being at the\ntoplevel (the case where \"git add -u :/\" and \"git add -u .\" have\ndifferent behavior)? E.g.,\n\n\t\tstatic const char *here[2] = { \".\", NULL };\n\t\tif (prefix)\n\t\t\twarning(...);\n\nThanks,\nJonathan\n"},{"id":"207452","messageId":"7vbocif7md.fsf@alter.siamese.dyndns.org","threadId":"32672","inReplyTo":"vpqhamapal1.fsf@grenoble-inp.fr","subject":"Re: [RFC] git rm -u","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-21T23:18:02Z","receivedAt":"2013-01-21T23:18:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Junio C Hamano writes:\n>\n>> But v1.5.2.5~1 (git-add -u paths... now works from subdirectory,\n>> 2007-08-16) changed the semantics to limit the operation to the\n>> working tree.\n>\n> Not really. It fixed \"git add -u path\", not plain \"git add -u\". A quick\n> test checking out and compiling v1.5.2.5~1^ shows that \"git add -u .\"\n> from a subdirectory was adding everything from the root.\n>\n> My interpretation is that v1.5.2.5~1 fixed an actual bug, without\n> thinking about what would happen when \"git add -u\" was called without\n> path, so the behavior is \"what happens to be the most natural to\n> implement\".\n\nI guess at this point it does not matter that much if that was an\nunintended consequence of a buggy fix, or a new behaviour by design.\nWe initially were tree-wide but later limited the operation to the\ncurrent directory.\n\nI think your \"Check 'git diff' then run 'git add -u'\" example may be\na good enough argument that it is a good idea to restore the\noriginally intended \"tree-wide\" behaviour in any case.\n"},{"id":"207462","messageId":"CACsJy8B1=3gMfGUf3kyea9TyZmr1J7dbM1_+huMNrep24hwuiQ@mail.gmail.com","threadId":"32672","inReplyTo":"1358769611-3625-1-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-01-22T01:10:34Z","receivedAt":"2013-01-22T01:10:34Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Jan 21, 2013 at 7:00 PM, Matthieu Moy wrote:\n> Most git commands that can be used with our without a filepattern are\n> tree-wide by default, the filepattern being used to restrict their scope.\n> A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'.\n>\n> The inconsistancy of 'git add -u' and 'git add -A' are particularly\n> problematic since other 'git add' subcommands (namely 'git add -p' and\n> 'git add -e') are tree-wide by default.\n>\n> Flipping the default now is unacceptable, so this patch starts training\n> users to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare\n> for the next steps:\n>\n> * forbid 'git add -u|-A' without filepattern (like 'git add' without\n> option)\n>\n> * much later, maybe, re-allow 'git add -u|-A' without filepattern, with a\n> tree-wide scope.\n\nWhat about 'grep' and 'clean'? I think at least 'clean' should go\ntree-wide default too. I don't mind grep go the same way either but I\nthink people voiced preference in current behavior..\n-- \nDuy\n"},{"id":"207464","messageId":"7vsj5uc7db.fsf@alter.siamese.dyndns.org","threadId":"32672","inReplyTo":"CACsJy8B1=3gMfGUf3kyea9TyZmr1J7dbM1_+huMNrep24hwuiQ@mail.gmail.com","subject":"Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-22T01:51:44Z","receivedAt":"2013-01-22T01:51:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> What about 'grep' and 'clean'? I think at least 'clean' should go\n> tree-wide default too. I don't mind grep go the same way either but I\n> think people voiced preference in current behavior..\n\nI think the major argument for \"git grep\" to be the way it is is\nbecause people expect it to be extension of running \"grep -r\" in the\nsame directory (\"git grep\" excludes untracked ones so you do not\nhave to suffer from --exclude=.git and such unpleasantries).\n\nShouldn't \"git clean\" be an extension of running \"rm -r\" in the same\ndirectory (\"git clean\" does not lose tracked ones but otherwise it\nis a recursive removal)?\n"},{"id":"207485","messageId":"vpq1uddoedj.fsf@grenoble-inp.fr","threadId":"32672","inReplyTo":"20130121222248.GA3586@elie.Belkin","subject":"Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-01-22T07:39:36Z","receivedAt":"2013-01-22T07:39:36Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jonathan Nieder writes:\n\n> Would it be possible to make this conditional on cwd not being at the\n> toplevel (the case where \"git add -u :/\" and \"git add -u .\" have\n> different behavior)? E.g.,\n>\n> \t\tstatic const char *here[2] = { \".\", NULL };\n> \t\tif (prefix)\n> \t\t\twarning(...);\n\nI thought about this too, after writting the patch. Actually, I still I\nit makes sense to warn even from the toplevel, since the point is to\nteach people to stop using pathless \"git add -u\" for a while, so I'd say\nit's easier to teach this in every condition. OTOH, the next step\n(forbidding pathless \"git add -u\") can still allow it from the toplevel\nto minimize the pain.\n\nBut I'm starting to be convinced ;-).\n\nAny other thought on the question?\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"207801","messageId":"1359110978-20054-1-git-send-email-Matthieu.Moy@imag.fr","threadId":"32672","inReplyTo":"vpq1uddoedj.fsf@grenoble-inp.fr","subject":"[PATCH v2] add: warn when -u or -A is used without filepattern","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2013-01-25T10:49:38Z","receivedAt":"2013-01-25T10:49:38Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Most git commands that can be used with our without a filepattern are\ntree-wide by default, the filepattern being used to restrict their scope.\nA few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'.\n\nThe inconsistancy of 'git add -u' and 'git add -A' are particularly\nproblematic since other 'git add' subcommands (namely 'git add -p' and\n'git add -e') are tree-wide by default.\n\nFlipping the default now is unacceptable, so this patch starts training\nusers to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare\nfor the next steps:\n\n* forbid 'git add -u|-A' without filepattern (like 'git add' without\n option)\n\n* much later, maybe, re-allow 'git add -u|-A' without filepattern, with a\n tree-wide scope.\n\nA nice side effect of this patch is that it makes the :/ special\nfilepattern easier to discover for users.\n\nWhen the command is called from the root of the tree, there is no\nambiguity and no need to change the behavior, hence no need to warn.\n\nSigned-off-by: Matthieu Moy \n---\nChanges since v1:\n\n* Do not warn from the root of the tree.\n\n* Say explicitely \"Git 2.0\" to announce the change.\n\n(plus fix a C99 style issue)\n\n Documentation/git-add.txt | 7 ++++---\n builtin/add.c | 36 +++++++++++++++++++++++++++++++++++-\n 2 files changed, 39 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-add.txt b/Documentation/git-add.txt\nindex fd9e36b..5333559 100644\n--- a/Documentation/git-add.txt\n+++ b/Documentation/git-add.txt\n@@ -107,9 +107,10 @@ apply to the index. See EDITING PATCHES below.\n \tfrom the index if the corresponding files in the working tree\n \thave been removed.\n +\n-If no is given, default to \".\"; in other words,\n-update all tracked files in the current directory and its\n-subdirectories.\n+If no is given, the current version of Git defaults to\n+\".\"; in other words, update all tracked files in the current directory\n+and its subdirectories. This default will change in a future version\n+of Git, hence the form without should not be used.\n \n -A::\n --all::\ndiff --git a/builtin/add.c b/builtin/add.c\nindex e664100..8252d19 100644\n--- a/builtin/add.c\n+++ b/builtin/add.c\n@@ -363,6 +363,33 @@ static int add_files(struct dir_struct *dir, int flags)\n \treturn exit_status;\n }\n \n+static void warn_pathless_add(const char *option_name) {\n+\t/*\n+\t * To be consistant with \"git add -p\" and most Git\n+\t * commands, we should default to being tree-wide, but\n+\t * this is not the original behavior and can't be\n+\t * changed until users trained themselves not to type\n+\t * \"git add -u\" or \"git add -A\". For now, we warn and\n+\t * keep the old behavior. Later, this warning can be\n+\t * turned into a die(...), and eventually we may\n+\t * reallow the command with a new behavior.\n+\t */\n+\twarning(_(\"The behavior of 'git add %s' with no path argument from a subdirectory of the\\n\"\n+\t\t \"tree will change in Git 2.0 and shouldn't be used anymore.\\n\"\n+\t\t \"To add content for the whole tree, run:\\n\"\n+\t\t \"\\n\"\n+\t\t \" git add %s :/\\n\"\n+\t\t \"\\n\"\n+\t\t \"To restrict the command to the current directory, run:\\n\"\n+\t\t \"\\n\"\n+\t\t \" git add %s .\\n\"\n+\t\t \"\\n\"\n+\t\t \"With the current Git version, the command is restricted to the current directory.\"),\n+\t\toption_name,\n+\t\toption_name,\n+\t\toption_name);\n+}\n+\n int cmd_add(int argc, const char **argv, const char *prefix)\n {\n \tint exit_status = 0;\n@@ -373,6 +400,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \tint add_new_files;\n \tint require_pathspec;\n \tchar *seen = NULL;\n+\tconst char *option_with_implicit_dot = NULL;\n \n \tgit_config(add_config, NULL);\n \n@@ -392,8 +420,14 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \t\tdie(_(\"-A and -u are mutually incompatible\"));\n \tif (!show_only && ignore_missing)\n \t\tdie(_(\"Option --ignore-missing can only be used together with --dry-run\"));\n-\tif ((addremove || take_worktree_changes) && !argc) {\n+\tif (addremove)\n+\t\toption_with_implicit_dot = \"--all\";\n+\tif (take_worktree_changes)\n+\t\toption_with_implicit_dot = \"--update\";\n+\tif (option_with_implicit_dot && !argc) {\n \t\tstatic const char *here[2] = { \".\", NULL };\n+\t\tif (prefix)\n+\t\t\twarn_pathless_add(option_with_implicit_dot);\n \t\targc = 1;\n \t\targv = here;\n \t}\n-- \n1.8.0.1.527.gd366564.dirty\n"},{"id":"207827","messageId":"7v8v7h3vx8.fsf@alter.siamese.dyndns.org","threadId":"32672","inReplyTo":"1359110978-20054-1-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [PATCH v2] add: warn when -u or -A is used without filepattern","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-25T19:27:31Z","receivedAt":"2013-01-25T19:27:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Most git commands that can be used with our without a filepattern are\n> tree-wide by default, the filepattern being used to restrict their scope.\n> A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'.\n>\n> The inconsistancy of 'git add -u' and 'git add -A' are particularly\n\ns/consistan/consisten/;\n\n> diff --git a/builtin/add.c b/builtin/add.c\n> index e664100..8252d19 100644\n> --- a/builtin/add.c\n> +++ b/builtin/add.c\n> @@ -363,6 +363,33 @@ static int add_files(struct dir_struct *dir, int flags)\n> \treturn exit_status;\n> }\n> \n> +static void warn_pathless_add(const char *option_name) {\n> +\t/*\n> +\t * To be consistant with \"git add -p\" and most Git\n\nLikewise.\n\n> +\twarning(_(\"The behavior of 'git add %s' with no path argument from a subdirectory of the\\n\"\n> ...\n> +\t\toption_name,\n> +\t\toption_name,\n> +\t\toption_name);\n> +}\n> +\n> int cmd_add(int argc, const char **argv, const char *prefix)\n> {\n> \tint exit_status = 0;\n> @@ -392,8 +420,14 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n> \t\tdie(_(\"-A and -u are mutually incompatible\"));\n> \tif (!show_only && ignore_missing)\n> \t\tdie(_(\"Option --ignore-missing can only be used together with --dry-run\"));\n> -\tif ((addremove || take_worktree_changes) && !argc) {\n> +\tif (addremove)\n> +\t\toption_with_implicit_dot = \"--all\";\n> +\tif (take_worktree_changes)\n> +\t\toption_with_implicit_dot = \"--update\";\n\nI wonder if we want to say in the message\n\n\tThe behaviour of 'git add --all (or -A)'...\n\notherwise people who typed \"git add -A\" and got this message with\njust \"--all\" may go \"Huh?\" for a brief moment. I however do not\nthink replacing these strings to\n\n\toption_with_implicit_dot = \"--all (-A)\";\n\nis a solution, given they are goven to _(\"l10n template %s\").\n\nOther than that the patch looks reasonable.\n\nThanks.\n"},{"id":"207948","messageId":"20130127122226.GB7670@elie.Belkin","threadId":"32672","inReplyTo":"1359110978-20054-1-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [PATCH v2] add: warn when -u or -A is used without filepattern","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-01-27T12:22:26Z","receivedAt":"2013-01-27T12:22:26Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Matthieu,\n\nMatthieu Moy wrote:\n\n> --- a/builtin/add.c\n> +++ b/builtin/add.c\n[...]\n> @@ -392,8 +420,14 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n> \t\tdie(_(\"-A and -u are mutually incompatible\"));\n> \tif (!show_only && ignore_missing)\n> \t\tdie(_(\"Option --ignore-missing can only be used together with --dry-run\"));\n> -\tif ((addremove || take_worktree_changes) && !argc) {\n> +\tif (addremove)\n> +\t\toption_with_implicit_dot = \"--all\";\n> +\tif (take_worktree_changes)\n> +\t\toption_with_implicit_dot = \"--update\";\n\nI agree with Junio that these are most often spelled as \"-A\" and \"-u\".\n\n> +\tif (option_with_implicit_dot && !argc) {\n> \t\tstatic const char *here[2] = { \".\", NULL };\n> +\t\tif (prefix)\n> +\t\t\twarn_pathless_add(option_with_implicit_dot);\n\nFor what it's worth, with or without s/--all/-A/ and s/--update/-u/,\nReviewed-by: Jonathan Nieder \n\nThanks. If someone wants to preserve the spelling of the option name\npassed by the user, that can happen as a patch on top.\n"},{"id":"207960","messageId":"vpqtxq28v3s.fsf@grenoble-inp.fr","threadId":"32672","inReplyTo":"7v8v7h3vx8.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] add: warn when -u or -A is used without filepattern","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-01-27T16:10:47Z","receivedAt":"2013-01-27T16:10:47Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Matthieu Moy writes:\n>\n>> Most git commands that can be used with our without a filepattern are\n>> tree-wide by default, the filepattern being used to restrict their scope.\n>> A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'.\n>>\n>> The inconsistancy of 'git add -u' and 'git add -A' are particularly\n>\n> s/consistan/consisten/;\n\nThanks, will fix.\n\n> I wonder if we want to say in the message\n>\n> \tThe behaviour of 'git add --all (or -A)'...\n>\n> otherwise people who typed \"git add -A\" and got this message with\n> just \"--all\" may go \"Huh?\" for a brief moment. I however do not\n> think replacing these strings to\n>\n> \toption_with_implicit_dot = \"--all (-A)\";\n>\n> is a solution, given they are goven to _(\"l10n template %s\").\n\nPlus, option_with_implicit_dot is used in cut-and-paste ready commands\nbelow. I can easily add another variable short_option or so to display\nboth. Ideally, we should use whatever the user had typed, but that does\nnot seem easy to do with parse-option so I'd say it's overkill.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"207982","messageId":"7vehh6v01v.fsf@alter.siamese.dyndns.org","threadId":"32672","inReplyTo":"vpqtxq28v3s.fsf@grenoble-inp.fr","subject":"Re: [PATCH v2] add: warn when -u or -A is used without filepattern","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-27T20:33:00Z","receivedAt":"2013-01-27T20:33:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Plus, option_with_implicit_dot is used in cut-and-paste ready commands\n> below.\n\nI do not think we should aim for easy cut-and-paste, especially when\nthe real purpose of the change is to train people's fingers; the\nmessage should discouraging cut-and-paste in a case like this, if\nanything.\n\nBut we could obviously do this, if you really want to cut-and-paste.\n\n builtin/add.c | 29 ++++++++++++++++++-----------\n 1 file changed, 18 insertions(+), 11 deletions(-)\n\ndiff --git a/builtin/add.c b/builtin/add.c\nindex 7552f7f..ba72a57 100644\n--- a/builtin/add.c\n+++ b/builtin/add.c\n@@ -363,7 +363,7 @@ static int add_files(struct dir_struct *dir, int flags)\n \treturn exit_status;\n }\n \n-static void warn_pathless_add(const char *option_name) {\n+static void warn_pathless_add(const char *option_name, const char *short_name) {\n \t/*\n \t * To be consistent with \"git add -p\" and most Git\n \t * commands, we should default to being tree-wide, but\n@@ -374,20 +374,21 @@ static void warn_pathless_add(const char *option_name) {\n \t * turned into a die(...), and eventually we may\n \t * reallow the command with a new behavior.\n \t */\n-\twarning(_(\"The behavior of 'git add %s' with no path argument from a subdirectory of the\\n\"\n-\t\t \"tree will change in Git 2.0 and shouldn't be used anymore.\\n\"\n+\twarning(_(\"The behavior of 'git add %s (or %s)' with no path argument from a\\n\"\n+\t\t \"subdirectory of the tree will change in Git 2.0 and should not be\\n\"\n+\t\t \"used anymore.\\n\"\n \t\t \"To add content for the whole tree, run:\\n\"\n \t\t \"\\n\"\n-\t\t \" git add %s :/\\n\"\n+\t\t \" git add %s :/ ;# or git add %s :/\\n\"\n \t\t \"\\n\"\n \t\t \"To restrict the command to the current directory, run:\\n\"\n \t\t \"\\n\"\n-\t\t \" git add %s .\\n\"\n+\t\t \" git add %s . ;# or git add %s .\\n\"\n \t\t \"\\n\"\n \t\t \"With the current Git version, the command is restricted to the current directory.\"),\n-\t\toption_name,\n-\t\toption_name,\n-\t\toption_name);\n+\t\toption_name, short_name,\n+\t\toption_name, short_name,\n+\t\toption_name, short_name);\n }\n \n int cmd_add(int argc, const char **argv, const char *prefix)\n@@ -401,6 +402,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \tint require_pathspec;\n \tchar *seen = NULL;\n \tconst char *option_with_implicit_dot = NULL;\n+\tconst char *short_option_with_implicit_dot = NULL;\n \n \tgit_config(add_config, NULL);\n \n@@ -420,14 +422,19 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \t\tdie(_(\"-A and -u are mutually incompatible\"));\n \tif (!show_only && ignore_missing)\n \t\tdie(_(\"Option --ignore-missing can only be used together with --dry-run\"));\n-\tif (addremove)\n+\tif (addremove) {\n \t\toption_with_implicit_dot = \"--all\";\n-\tif (take_worktree_changes)\n+\t\tshort_option_with_implicit_dot = \"-A\";\n+\t}\n+\tif (take_worktree_changes) {\n \t\toption_with_implicit_dot = \"--update\";\n+\t\tshort_option_with_implicit_dot = \"-u\";\n+\t}\n \tif (option_with_implicit_dot && !argc) {\n \t\tstatic const char *here[2] = { \".\", NULL };\n \t\tif (prefix)\n-\t\t\twarn_pathless_add(option_with_implicit_dot);\n+\t\t\twarn_pathless_add(option_with_implicit_dot,\n+\t\t\t\t\t short_option_with_implicit_dot);\n \t\targc = 1;\n \t\targv = here;\n \t}\n"},{"id":"208071","messageId":"vpqobg966cv.fsf@grenoble-inp.fr","threadId":"32672","inReplyTo":"7vehh6v01v.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] add: warn when -u or -A is used without filepattern","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-01-28T08:48:16Z","receivedAt":"2013-01-28T08:48:16Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Matthieu Moy writes:\n>\n>> Plus, option_with_implicit_dot is used in cut-and-paste ready commands\n>> below.\n>\n> I do not think we should aim for easy cut-and-paste, especially when\n> the real purpose of the change is to train people's fingers; the\n> message should discouraging cut-and-paste in a case like this, if\n> anything.\n\ncut-and-paste readyness is also a way to avoid being ambiguous. If you\ntell users to run \"git add -u (--update)\", you'll always find someone to\ntype the command as-is and complain about it not working (sadly, the\nteacher living inside me is speaking of experience ;-) ).\n\n> But we could obviously do this, if you really want to cut-and-paste.\n\nI was going to do something like this, you've been too quick ;-).\n\nResend comming soon.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"208073","messageId":"1359364593-10933-1-git-send-email-Matthieu.Moy@imag.fr","threadId":"32672","inReplyTo":"vpqobg966cv.fsf@grenoble-inp.fr","subject":"[PATCH v3] add: warn when -u or -A is used without filepattern","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2013-01-28T09:16:33Z","receivedAt":"2013-01-28T09:16:33Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Most git commands that can be used with our without a filepattern are\ntree-wide by default, the filepattern being used to restrict their scope.\nA few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'.\n\nThe inconsistency of 'git add -u' and 'git add -A' are particularly\nproblematic since other 'git add' subcommands (namely 'git add -p' and\n'git add -e') are tree-wide by default.\n\nFlipping the default now is unacceptable, so this patch starts training\nusers to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare\nfor the next steps:\n\n* forbid 'git add -u|-A' without filepattern (like 'git add' without\n option)\n\n* much later, maybe, re-allow 'git add -u|-A' without filepattern, with a\n tree-wide scope.\n\nA nice side effect of this patch is that it makes the :/ special\nfilepattern easier to discover for users.\n\nWhen the command is called from the root of the tree, there is no\nambiguity and no need to change the behavior, hence no need to warn.\n\nSigned-off-by: Matthieu Moy \n---\nChanges since v2:\n\n* Typo consistant -> consistent\n\n* Mention both short and long option names (Thanks Junio). I went for\n a two-lines display which I find a bit nicer to read than Junio's\n version, but I'm fine with both.\n\n Documentation/git-add.txt | 7 ++++---\n builtin/add.c | 44 +++++++++++++++++++++++++++++++++++++++++++-\n 2 files changed, 47 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-add.txt b/Documentation/git-add.txt\nindex fd9e36b..5333559 100644\n--- a/Documentation/git-add.txt\n+++ b/Documentation/git-add.txt\n@@ -107,9 +107,10 @@ apply to the index. See EDITING PATCHES below.\n \tfrom the index if the corresponding files in the working tree\n \thave been removed.\n +\n-If no is given, default to \".\"; in other words,\n-update all tracked files in the current directory and its\n-subdirectories.\n+If no is given, the current version of Git defaults to\n+\".\"; in other words, update all tracked files in the current directory\n+and its subdirectories. This default will change in a future version\n+of Git, hence the form without should not be used.\n \n -A::\n --all::\ndiff --git a/builtin/add.c b/builtin/add.c\nindex 7cb6cca..7738025 100644\n--- a/builtin/add.c\n+++ b/builtin/add.c\n@@ -321,6 +321,35 @@ static int add_files(struct dir_struct *dir, int flags)\n \treturn exit_status;\n }\n \n+static void warn_pathless_add(const char *option_name, const char *short_name) {\n+\t/*\n+\t * To be consistent with \"git add -p\" and most Git\n+\t * commands, we should default to being tree-wide, but\n+\t * this is not the original behavior and can't be\n+\t * changed until users trained themselves not to type\n+\t * \"git add -u\" or \"git add -A\". For now, we warn and\n+\t * keep the old behavior. Later, this warning can be\n+\t * turned into a die(...), and eventually we may\n+\t * reallow the command with a new behavior.\n+\t */\n+\twarning(_(\"The behavior of 'git add %s (or %s)' with no path argument from a\\n\"\n+\t\t \"subdirectory of the tree will change in Git 2.0 and should not be used anymore.\\n\"\n+\t\t \"To add content for the whole tree, run:\\n\"\n+\t\t \"\\n\"\n+\t\t \" git add %s :/\\n\"\n+\t\t \" (or git add %s :/)\\n\"\n+\t\t \"\\n\"\n+\t\t \"To restrict the command to the current directory, run:\\n\"\n+\t\t \"\\n\"\n+\t\t \" git add %s .\\n\"\n+\t\t \" (or git add %s .)\\n\"\n+\t\t \"\\n\"\n+\t\t \"With the current Git version, the command is restricted to the current directory.\"),\n+\t\toption_name, short_name,\n+\t\toption_name, short_name,\n+\t\toption_name, short_name);\n+}\n+\n int cmd_add(int argc, const char **argv, const char *prefix)\n {\n \tint exit_status = 0;\n@@ -331,6 +360,8 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \tint add_new_files;\n \tint require_pathspec;\n \tchar *seen = NULL;\n+\tconst char *option_with_implicit_dot = NULL;\n+\tconst char *short_option_with_implicit_dot = NULL;\n \n \tgit_config(add_config, NULL);\n \n@@ -350,8 +381,19 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \t\tdie(_(\"-A and -u are mutually incompatible\"));\n \tif (!show_only && ignore_missing)\n \t\tdie(_(\"Option --ignore-missing can only be used together with --dry-run\"));\n-\tif ((addremove || take_worktree_changes) && !argc) {\n+\tif (addremove) {\n+\t\toption_with_implicit_dot = \"--all\";\n+\t\tshort_option_with_implicit_dot = \"-A\";\n+\t}\n+\tif (take_worktree_changes) {\n+\t\toption_with_implicit_dot = \"--update\";\n+\t\tshort_option_with_implicit_dot = \"-u\";\n+\t}\n+\tif (option_with_implicit_dot && !argc) {\n \t\tstatic const char *here[2] = { \".\", NULL };\n+\t\tif (prefix)\n+\t\t\twarn_pathless_add(option_with_implicit_dot,\n+\t\t\t\t\t short_option_with_implicit_dot);\n \t\targc = 1;\n \t\targv = here;\n \t}\n-- \n1.8.1.1.440.g1d329bd.dirty\n"},{"id":"208075","messageId":"20130128092041.GA3346@elie.Belkin","threadId":"32672","inReplyTo":"1359364593-10933-1-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [PATCH v3] add: warn when -u or -A is used without filepattern","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-01-28T09:20:41Z","receivedAt":"2013-01-28T09:20:41Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Matthieu Moy wrote:\n\n> Signed-off-by: Matthieu Moy \n\nLooks good to me.\n\nAt some point we'll want to have tests for this case, but that's not\nparticularly urgent until it's time for the warning() to turn into a\ndie().\n\nThanks.\nJonathan\n"},{"id":"208085","messageId":"51067353.2090006@drmicha.warpmail.net","threadId":"32672","inReplyTo":"1359364593-10933-1-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [PATCH v3] add: warn when -u or -A is used without filepattern","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2013-01-28T12:47:15Z","receivedAt":"2013-01-28T12:47:15Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Matthieu Moy venit, vidit, dixit 28.01.2013 10:16:\n> Most git commands that can be used with our without a filepattern are\n> tree-wide by default, the filepattern being used to restrict their scope.\n> A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'.\n\nSince I didn't follow this thread, my first reaction was: \"Huh? Aren't\nthey treewide?\" (for the relative tree)\n\nSo, for someone reading just the commit message, it would be helpful to\nsay what the others do, i.e. default to the relative tree at pwd (rather\nthan defaulting to an empty tree, or all files whether tracked or not,\nor...).\n\nOtherwise, I'd rather switch sooner than later; it's so easy to take\n\"git add -u && git commit == git commit -a\" for granted and to miss\nstaging some hunks. But 2.0 is around the corner anyway, isn't it ;)\n\n> The inconsistency of 'git add -u' and 'git add -A' are particularly\n> problematic since other 'git add' subcommands (namely 'git add -p' and\n> 'git add -e') are tree-wide by default.\n> \n> Flipping the default now is unacceptable, so this patch starts training\n> users to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare\n> for the next steps:\n> \n> * forbid 'git add -u|-A' without filepattern (like 'git add' without\n> option)\n> \n> * much later, maybe, re-allow 'git add -u|-A' without filepattern, with a\n> tree-wide scope.\n> \n> A nice side effect of this patch is that it makes the :/ special\n> filepattern easier to discover for users.\n> \n> When the command is called from the root of the tree, there is no\n> ambiguity and no need to change the behavior, hence no need to warn.\n> \n> Signed-off-by: Matthieu Moy \n> ---\n> Changes since v2:\n> \n> * Typo consistant -> consistent\n> \n> * Mention both short and long option names (Thanks Junio). I went for\n> a two-lines display which I find a bit nicer to read than Junio's\n> version, but I'm fine with both.\n> \n> Documentation/git-add.txt | 7 ++++---\n> builtin/add.c | 44 +++++++++++++++++++++++++++++++++++++++++++-\n> 2 files changed, 47 insertions(+), 4 deletions(-)\n> \n> diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt\n> index fd9e36b..5333559 100644\n> --- a/Documentation/git-add.txt\n> +++ b/Documentation/git-add.txt\n> @@ -107,9 +107,10 @@ apply to the index. See EDITING PATCHES below.\n> \tfrom the index if the corresponding files in the working tree\n> \thave been removed.\n> +\n> -If no is given, default to \".\"; in other words,\n> -update all tracked files in the current directory and its\n> -subdirectories.\n> +If no is given, the current version of Git defaults to\n> +\".\"; in other words, update all tracked files in the current directory\n> +and its subdirectories. This default will change in a future version\n> +of Git, hence the form without should not be used.\n> \n> -A::\n> --all::\n> diff --git a/builtin/add.c b/builtin/add.c\n> index 7cb6cca..7738025 100644\n> --- a/builtin/add.c\n> +++ b/builtin/add.c\n> @@ -321,6 +321,35 @@ static int add_files(struct dir_struct *dir, int flags)\n> \treturn exit_status;\n> }\n> \n> +static void warn_pathless_add(const char *option_name, const char *short_name) {\n> +\t/*\n> +\t * To be consistent with \"git add -p\" and most Git\n> +\t * commands, we should default to being tree-wide, but\n> +\t * this is not the original behavior and can't be\n> +\t * changed until users trained themselves not to type\n> +\t * \"git add -u\" or \"git add -A\". For now, we warn and\n> +\t * keep the old behavior. Later, this warning can be\n> +\t * turned into a die(...), and eventually we may\n> +\t * reallow the command with a new behavior.\n> +\t */\n> +\twarning(_(\"The behavior of 'git add %s (or %s)' with no path argument from a\\n\"\n> +\t\t \"subdirectory of the tree will change in Git 2.0 and should not be used anymore.\\n\"\n> +\t\t \"To add content for the whole tree, run:\\n\"\n> +\t\t \"\\n\"\n> +\t\t \" git add %s :/\\n\"\n> +\t\t \" (or git add %s :/)\\n\"\n> +\t\t \"\\n\"\n> +\t\t \"To restrict the command to the current directory, run:\\n\"\n> +\t\t \"\\n\"\n> +\t\t \" git add %s .\\n\"\n> +\t\t \" (or git add %s .)\\n\"\n> +\t\t \"\\n\"\n> +\t\t \"With the current Git version, the command is restricted to the current directory.\"),\n> +\t\toption_name, short_name,\n> +\t\toption_name, short_name,\n> +\t\toption_name, short_name);\n> +}\n> +\n> int cmd_add(int argc, const char **argv, const char *prefix)\n> {\n> \tint exit_status = 0;\n> @@ -331,6 +360,8 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n> \tint add_new_files;\n> \tint require_pathspec;\n> \tchar *seen = NULL;\n> +\tconst char *option_with_implicit_dot = NULL;\n> +\tconst char *short_option_with_implicit_dot = NULL;\n> \n> \tgit_config(add_config, NULL);\n> \n> @@ -350,8 +381,19 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n> \t\tdie(_(\"-A and -u are mutually incompatible\"));\n> \tif (!show_only && ignore_missing)\n> \t\tdie(_(\"Option --ignore-missing can only be used together with --dry-run\"));\n> -\tif ((addremove || take_worktree_changes) && !argc) {\n> +\tif (addremove) {\n> +\t\toption_with_implicit_dot = \"--all\";\n> +\t\tshort_option_with_implicit_dot = \"-A\";\n> +\t}\n> +\tif (take_worktree_changes) {\n> +\t\toption_with_implicit_dot = \"--update\";\n> +\t\tshort_option_with_implicit_dot = \"-u\";\n> +\t}\n> +\tif (option_with_implicit_dot && !argc) {\n> \t\tstatic const char *here[2] = { \".\", NULL };\n> +\t\tif (prefix)\n> +\t\t\twarn_pathless_add(option_with_implicit_dot,\n> +\t\t\t\t\t short_option_with_implicit_dot);\n> \t\targc = 1;\n> \t\targv = here;\n> \t}\n> \n"},{"id":"208096","messageId":"7v4ni1xjuc.fsf@alter.siamese.dyndns.org","threadId":"32672","inReplyTo":"51067353.2090006@drmicha.warpmail.net","subject":"Re: [PATCH v3] add: warn when -u or -A is used without filepattern","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-28T18:07:07Z","receivedAt":"2013-01-28T18:07:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> Matthieu Moy venit, vidit, dixit 28.01.2013 10:16:\n>> Most git commands that can be used with our without a filepattern are\n>> tree-wide by default, the filepattern being used to restrict their scope.\n>> A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'.\n>\n> Since I didn't follow this thread, my first reaction was: \"Huh? Aren't\n> they treewide?\" (for the relative tree)\n>\n> So, for someone reading just the commit message, it would be helpful to\n> say what the others do, i.e. default to the relative tree at pwd (rather\n> than defaulting to an empty tree, or all files whether tracked or not,\n> or...).\n\nI think \"add -u && commit\" vs \"commit -a\" you brought up is a good\nthing to mention, so let's do this. Another tweak is that I did\ns/filepattern/pathspec/ here. I know that both the documentation\nand the help text for \"git add\" say filepattern, but we say pathspec\nstarting from glossary fairly consistently everywhere in the rest of\nthe system.\n\nWe should probably update the documentation/help for \"git add\", but\nthat is entirely a separate topic.\n\n add: warn when -u or -A is used without pathspec\n \n Most Git commands that can be used with or without pathspec operate\n tree-wide by default, the pathspec being used to restrict their\n scope. A few exceptions are: 'git grep', 'git clean', 'git add -u'\n and 'git add -A'. When run in a subdirectory without pathspec, they\n operate only on paths in the current directory.\n \n The inconsistency of 'git add -u' and 'git add -A' are particularly\n problematic since other 'git add' subcommands (namely 'git add -p'\n and 'git add -e') are tree-wide by default. It also means that \"git\n add -u && git commit\" will record a state that is different from\n what is recorded with \"git commit -a\".\n \n Flipping the default now is unacceptable, so let's start training\n users to type 'git add -u|-A :/' or 'git add -u|-A .' explicitly, to\n prepare for the next steps:\n \n * forbid 'git add -u|-A' without pathspec (like 'git add' without\n option)\n \n * much later, maybe, re-allow 'git add -u|-A' without pathspec, that\n will add all tracked and modified files, or all files, tree-wide.\n \n A nice side effect of this patch is that it makes the :/ magic\n pathspec easier to discover for users.\n \n When the command is called from the root of the tree, there is no\n ambiguity and no need to change the behavior, hence no need to warn.\n \n Signed-off-by: Matthieu Moy \n Signed-off-by: Junio C Hamano \n"},{"id":"208098","messageId":"vpq8v7dw4f5.fsf@grenoble-inp.fr","threadId":"32672","inReplyTo":"7v4ni1xjuc.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v3] add: warn when -u or -A is used without filepattern","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-01-28T18:25:34Z","receivedAt":"2013-01-28T18:25:34Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> I think \"add -u && commit\" vs \"commit -a\" you brought up is a good\n> thing to mention, so let's do this.\n\nI'm OK with your proposal. Let me know if you want me to resend.\n\n> The inconsistency of 'git add -u' and 'git add -A' are particularly\n\nNitpick: this should be \"inconsistencies\" (or \"is particularly\").\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"208100","messageId":"7vzjztw459.fsf@alter.siamese.dyndns.org","threadId":"32672","inReplyTo":"vpq8v7dw4f5.fsf@grenoble-inp.fr","subject":"Re: [PATCH v3] add: warn when -u or -A is used without filepattern","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-28T18:31:30Z","receivedAt":"2013-01-28T18:31:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Junio C Hamano writes:\n>\n>> I think \"add -u && commit\" vs \"commit -a\" you brought up is a good\n>> thing to mention, so let's do this.\n>\n> I'm OK with your proposal. Let me know if you want me to resend.\n\nThanks for a quick response. As you may have guessed, I am sending\nthese after running \"commit --amend\", so ...\n\n>> The inconsistency of 'git add -u' and 'git add -A' are particularly\n>\n> Nitpick: this should be \"inconsistencies\" (or \"is particularly\").\n\n... it is much easier for me to fix these locally instead of getting\na reroll.\n\nWill amend with s/are particularly/is particularly/; thanks.\n"},{"id":"209545","messageId":"7vr4kiwjqp.fsf@alter.siamese.dyndns.org","threadId":"32672","inReplyTo":"7v4ni1xjuc.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v3] add: warn when -u or -A is used without filepattern","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-14T23:36:46Z","receivedAt":"2013-02-14T23:36:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> We should probably update the documentation/help for \"git add\", but\n> that is entirely a separate topic.\n\nThe documentation update in 0fa2eb530fb7 (add: warn when -u or -A is\nused without pathspec, 2013-01-28) says:\n\n If no is given, the current version of Git defaults to\n \".\"; in other words, update all tracked files in the current directory\n and its subdirectories. This default will change in a future version\n of Git, hence the form without should not be used.\n\n(oops, I just spotted a stray here, which came from a\nsemantic mismerge---I'll fix it locally).\n\nThe above text says that we currently add what you have in your\ncurrent directory and below, before it says this default will\nchange. That makes it easier to connect \"the default will change\"\nand \"form without pathspec should not be used\" in readers' mind. It\ndoes not take that much imagination and intelligence to infer \"it\nwill change and will not limit to my current directory, so in the\nfuture I will have to be explicit when I want to do what I just told\ngit to do\".\n\nBut the warning text does not sound quite right. This is what I get:\n\n warning: The behavior of 'git add --update (or -u)' with no path argument from a\n subdirectory of the tree will change in Git 2.0 and should not be used anymore.\n\nThere is a logic gap between \"will change\" and \"should not be used\"\nthat is not filled like the text in the manual page does.\n"},{"id":"209546","messageId":"7vmwv6wivs.fsf@alter.siamese.dyndns.org","threadId":"32672","inReplyTo":"7vr4kiwjqp.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v3] add: warn when -u or -A is used without filepattern","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-14T23:55:19Z","receivedAt":"2013-02-14T23:55:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> warning: The behavior of 'git add --update (or -u)' with no path argument from a\n> subdirectory of the tree will change in Git 2.0 and should not be used anymore.\n>\n> There is a logic gap between \"will change\" and \"should not be used\"\n> that is not filled like the text in the manual page does.\n\nI guess it is not so bad after all, if you read the entire message,\nnot just the first two lines.\n"},{"id":"209550","messageId":"vpq4nhd6gmp.fsf@grenoble-inp.fr","threadId":"32672","inReplyTo":"7vmwv6wivs.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v3] add: warn when -u or -A is used without filepattern","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-02-15T10:00:46Z","receivedAt":"2013-02-15T10:00:46Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Junio C Hamano writes:\n>\n>> warning: The behavior of 'git add --update (or -u)' with no path argument from a\n>> subdirectory of the tree will change in Git 2.0 and should not be used anymore.\n>>\n>> There is a logic gap between \"will change\" and \"should not be used\"\n>> that is not filled like the text in the manual page does.\n>\n> I guess it is not so bad after all, if you read the entire message,\n> not just the first two lines.\n\nAlso, the warning is meant to be read by a user who just typed\n\"git add -u\", so it is expected that the user knows what it does in\ncurrent (or past) versions of Git.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"210229","messageId":"7vzjys28a0.fsf@alter.siamese.dyndns.org","threadId":"32672","inReplyTo":"50FB1673.8020808@gmail.com","subject":"Re: [RFC] git rm -u","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-25T06:54:15Z","receivedAt":"2013-02-25T06:54:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric James Michael Ritz writes:\n\n> On 01/19/2013 04:49 PM, Antoine Pelisse wrote:\n>> I think `git add -u` would be closer. It would stage removal of\n>> files, but would not stage untracked files. It would stage other\n>> type of changes though.\n>\n> On Sat, Jan 19, 2013 at 10:47 PM, Tomas Carnecky\n>> Does `git add -A` do what you want?\n>\n> Thank you Tomas and Antoine. Both of these commands do what I want:\n> stage deleted files on the index. But does the idea of a `git rm -u`\n> still sound useful since these commands also stage changes besides\n> deleted files?\n\nEven though I am not sure how often I would use it myself, \"reflect\nonly the removals in the working tree to the index, but exclude any\nother kind of changes\" might turn out to be a useful addition to the\ntoolchest in certain cases.\n\nI however am not yet convinced that \"git rm -u\" is a good way to\nexpress the feature at the UI. \"git add -u\" is \"update the index\nwith modification and removal but ignore new files because we won't\nknow if they are garbage or assets\". What the same \"-u\" option\nmeans in the context of \"git rm\" is not very clear, at least to me.\n"},{"id":"210270","messageId":"CALWbr2x9=+PEaGTpGWoqGiiupGsPhLoPcGknPb1WtSgxdpBkdQ@mail.gmail.com","threadId":"32672","inReplyTo":"7vzjys28a0.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] git rm -u","fromName":"Antoine Pelisse","fromEmail":"apelisse@gmail.com","sentAt":"2013-02-25T18:54:36Z","receivedAt":"2013-02-25T18:54:36Z","isPatch":false,"sender":{"key":"apelisse@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1929644?v=4"},"body":"I must say that I'm not very interested in the feature. In my opinion,\nthere are already many different ways to stage changes.\nAssuming that the feature would be needed, I would keep it under the\nscope of git-add, as it's the reference for staging. I would suggest\nsomething like:\n\n git add -r \"Stage removal of deleted files.\"\n\nOn Mon, Feb 25, 2013 at 7:54 AM, Junio C Hamano wrote:\n> Eric James Michael Ritz writes:\n>\n>> On 01/19/2013 04:49 PM, Antoine Pelisse wrote:\n>>> I think `git add -u` would be closer. It would stage removal of\n>>> files, but would not stage untracked files. It would stage other\n>>> type of changes though.\n>>\n>> On Sat, Jan 19, 2013 at 10:47 PM, Tomas Carnecky\n>>> Does `git add -A` do what you want?\n>>\n>> Thank you Tomas and Antoine. Both of these commands do what I want:\n>> stage deleted files on the index. But does the idea of a `git rm -u`\n>> still sound useful since these commands also stage changes besides\n>> deleted files?\n>\n> Even though I am not sure how often I would use it myself, \"reflect\n> only the removals in the working tree to the index, but exclude any\n> other kind of changes\" might turn out to be a useful addition to the\n> toolchest in certain cases.\n>\n> I however am not yet convinced that \"git rm -u\" is a good way to\n> express the feature at the UI. \"git add -u\" is \"update the index\n> with modification and removal but ignore new files because we won't\n> know if they are garbage or assets\". What the same \"-u\" option\n> means in the context of \"git rm\" is not very clear, at least to me.\n>\n>\n"},{"id":"210275","messageId":"vpq7glw5i20.fsf@grenoble-inp.fr","threadId":"32672","inReplyTo":"CALWbr2x9=+PEaGTpGWoqGiiupGsPhLoPcGknPb1WtSgxdpBkdQ@mail.gmail.com","subject":"Re: [RFC] git rm -u","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-02-25T19:07:03Z","receivedAt":"2013-02-25T19:07:03Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Antoine Pelisse writes:\n\n> I must say that I'm not very interested in the feature. In my opinion,\n> there are already many different ways to stage changes.\n> Assuming that the feature would be needed, I would keep it under the\n> scope of git-add, as it's the reference for staging. I would suggest\n> something like:\n>\n> git add -r \"Stage removal of deleted files.\"\n\nWould \"add -r\" stand for \"add --remove\"? That would be weird ...\n\n\"git rm\" really seems to be a better place for removing files from the\nindex.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"210278","messageId":"CALWbr2y-CN9A346avc4AG+FN9NHgPXKvWuU-nbcyjt08DavVjw@mail.gmail.com","threadId":"32672","inReplyTo":"vpq7glw5i20.fsf@grenoble-inp.fr","subject":"Re: [RFC] git rm -u","fromName":"Antoine Pelisse","fromEmail":"apelisse@gmail.com","sentAt":"2013-02-25T19:21:27Z","receivedAt":"2013-02-25T19:21:27Z","isPatch":false,"sender":{"key":"apelisse@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1929644?v=4"},"body":"On Mon, Feb 25, 2013 at 8:07 PM, Matthieu Moy\n wrote:\n> Antoine Pelisse writes:\n>\n>> I must say that I'm not very interested in the feature. In my opinion,\n>> there are already many different ways to stage changes.\n>> Assuming that the feature would be needed, I would keep it under the\n>> scope of git-add, as it's the reference for staging. I would suggest\n>> something like:\n>>\n>> git add -r \"Stage removal of deleted files.\"\n>\n> Would \"add -r\" stand for \"add --remove\"? That would be weird ...\n\nYes (for --remove),\nIt would not be weird if you consider the opposite of add to be reset\n(and not rm).\n\n> \"git rm\" really seems to be a better place for removing files from the\n> index.\n\nThen, I don't exactly understand the meaning of git-rm but being a\n_shortcut_ for \"remove and stage\". Here the files are already removed,\nwe only need to stage and the best command to stage changes is add.\n"},{"id":"210284","messageId":"vpqliac41zf.fsf@grenoble-inp.fr","threadId":"32672","inReplyTo":"CALWbr2y-CN9A346avc4AG+FN9NHgPXKvWuU-nbcyjt08DavVjw@mail.gmail.com","subject":"Re: [RFC] git rm -u","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-02-25T19:39:32Z","receivedAt":"2013-02-25T19:39:32Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Antoine Pelisse writes:\n\n>> \"git rm\" really seems to be a better place for removing files from the\n>> index.\n>\n> Then, I don't exactly understand the meaning of git-rm but being a\n> _shortcut_ for \"remove and stage\".\n\n\"git rm --cached\" is exactly \"remove from index\".\n\nAnd even without --cached, as you notice yourself, it does a \"remove and\nstage [removal]\", so why would it be inappropriate to stage a removal?\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"210285","messageId":"7v621gxjjx.fsf@alter.siamese.dyndns.org","threadId":"32672","inReplyTo":"vpqliac41zf.fsf@grenoble-inp.fr","subject":"Re: [RFC] git rm -u","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-25T19:47:14Z","receivedAt":"2013-02-25T19:47:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Antoine Pelisse writes:\n>\n>>> \"git rm\" really seems to be a better place for removing files from the\n>>> index.\n>>\n>> Then, I don't exactly understand the meaning of git-rm but being a\n>> _shortcut_ for \"remove and stage\".\n>\n> \"git rm --cached\" is exactly \"remove from index\".\n>\n> And even without --cached, as you notice yourself, it does a \"remove and\n> stage [removal]\", so why would it be inappropriate to stage a removal?\n\nI do not think \"git rm\" is a bad place to add the feature; I was\nquestioning if \"-u\" is an appropriate option. The option \"-u\" given\nto \"git add\" is internally called \"take worktree changes\", and we\nwould need the option to \"git rm\" with that internal meaning. The\nsuperficial meaning \"updated\" that \"-u\" in \"add -u\" stands for does\nnot really match what \"git rm --take-worktree-changes\" wants to do,\nas we obviously do not want to remove all updated/modified files.\n"}]}