{"thread":{"id":"43071","subject":"[RFC] A unique way to express \"all\" (vs \"add vs \"update\") ?","startedAt":"2006-12-15T11:38:51Z","lastAt":"2006-12-18T14:04:06Z","messageCount":6,"participants":["Jerome Lovy","Junio C Hamano","Carl Worth","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"293808","messageId":"elu1cn$k3$1@sea.gmane.org","threadId":"43071","inReplyTo":null,"subject":"[RFC] A unique way to express \"all\" (vs \"add vs \"update\") ?","fromName":"Jerome Lovy","fromEmail":"t2a2e9z8ncbs9qg@brefemail.com","sentAt":"2006-12-15T11:38:51Z","receivedAt":"2006-12-15T11:38:51Z","isPatch":false,"sender":{"key":"t2a2e9z8ncbs9qg@brefemail.com","avatar":null},"body":"Hi,\n\nWhile I am very happy with the refactorings undertaken with regard to\n\"git add/git commit\" (both for UI and documentation), I am still a\nlittle confused by the different ways I seem to find to express the idea\n\"I want to add (sort of) all file contents\".\n\nTo be more specific, I find the following in the current documentation:\n\ngit add \n\t\"adds content from all files under directory and its\n\tsubdirectories.\"\n\t(as interpreted from the \"EXAMPLES\" section of the git-add\n\tman-page)\n\t(BTW, could this usage be documented in the SYNOPSIS and\n\tDESCRIPTION sections (admittedly at a 2nd rank after the\n\tcurrently documented usage) as well as in the EXAMPLES ?\n\tBesides this reference sections would probably include the\n\t/ usage that I've not mentioned here for the sake\n\tof simplicity.)\n\t\n\tMoreover, the tutorial documents the typical usage \"git add .\"\n\ngit commit -a|--all\n\t\"automatically stage files that have been modified and deleted,\n\tbut new files you have not told git about are not affected.\"\n\nGranted, the latter semantics for \"all\" is not exactly the same as the\nformer. Nonetheless, I think it would be very nice to only have to \nmemorize one way to express \"all\".\n\nTo this end, I would be very happy with the following:\n(X-mas is coming soon, isn't it ;-) )\n\ngit add \n\tsame semantics\n\ngit commit -a|--add \n\t\"adds content from the specified files before committing\n\t(files that are already tracked have their current content\n\tstaged)\"\n\ngit commit -a|--add \n\t\"adds content from all files under directory and its\n\tsubdirectories before committing\"\n\t(once again, for simplification of my explanations, I omit the\n\t/ usage here)\n\ngit commit -u|--update \n\t\"automatically stage files that have been modified and deleted\n\tunder directory and its subdirectories, but new files you\n\thave not told git about are not affected.\"\n\t(once again, for simplification of my explanations, I omit the\n\t/ usage here)\n\n\t(This would allow the typical usage \"git commit -u .\" which is\n\tbarely longer than the current \"git commit -a\")\n\nFor interface completeness, \"git commit -u|--update \" could also\nexist but would probably be of no use.\n\nTo sum up, \"all\" would be consistently expressed with the syntax.\n\"git commit -a\" would not mean \"--all\" anymore. Lastly, a distinction\nwould be made between \"--add\" and \"--update\":\n- \"git commit -add\" would have the same semantics as \"git add\"\n- \"git commit --update\" on the other hand would only affect the files\n already tracked\n\nThank you for your patient attention.\nJérôme Lovy\n"},{"id":"297945","messageId":"4582906A.7020204@op5.se","threadId":"43071","inReplyTo":"elu1cn$k3$1@sea.gmane.org","subject":"Re: [RFC] A unique way to express \"all\" (vs \"add vs \"update\") ?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-12-15T12:09:14Z","receivedAt":"2006-12-15T12:09:14Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jerome Lovy wrote:\n> Hi,\n> \n> While I am very happy with the refactorings undertaken with regard to\n> \"git add/git commit\" (both for UI and documentation), I am still a\n> little confused by the different ways I seem to find to express the idea\n> \"I want to add (sort of) all file contents\".\n> \n> To be more specific, I find the following in the current documentation:\n> \n> git add \n> \"adds content from all files under directory and its\n> subdirectories.\"\n> (as interpreted from the \"EXAMPLES\" section of the git-add\n> man-page)\n> (BTW, could this usage be documented in the SYNOPSIS and\n> DESCRIPTION sections (admittedly at a 2nd rank after the\n> currently documented usage) as well as in the EXAMPLES ?\n> Besides this reference sections would probably include the\n> / usage that I've not mentioned here for the sake\n> of simplicity.)\n> \n> Moreover, the tutorial documents the typical usage \"git add .\"\n> \n> git commit -a|--all\n> \"automatically stage files that have been modified and deleted,\n> but new files you have not told git about are not affected.\"\n> \n> Granted, the latter semantics for \"all\" is not exactly the same as the\n> former. Nonetheless, I think it would be very nice to only have to \n> memorize one way to express \"all\".\n> \n\nBut the former isn't \"all\"; It's a specific directory, although \".\" \nhappens to *look* like \"all\", you can run \"git add .\" in a subdirectory \ninside the repository and it won't mean \"all\" anymore. Likewise, you can \nsay \"git commit .\" from a subdirectory and have it commit all changes to \nall tracked files under that directory.\n\n> To this end, I would be very happy with the following:\n> (X-mas is coming soon, isn't it ;-) )\n> \n> git add \n> same semantics\n> \n> git commit -a|--add \n> \"adds content from the specified files before committing\n> (files that are already tracked have their current content\n> staged)\"\n> \n> git commit -a|--add \n> \"adds content from all files under directory and its\n> subdirectories before committing\"\n> (once again, for simplification of my explanations, I omit the\n> / usage here)\n> \n> git commit -u|--update \n> \"automatically stage files that have been modified and deleted\n> under directory and its subdirectories, but new files you\n> have not told git about are not affected.\"\n> (once again, for simplification of my explanations, I omit the\n> / usage here)\n> \n\nBut this isn't \"commit\" at all. It's \"git add\".\n\n> (This would allow the typical usage \"git commit -u .\" which is\n> barely longer than the current \"git commit -a\")\n> \n> For interface completeness, \"git commit -u|--update \" could also\n> exist but would probably be of no use.\n> \n> To sum up, \"all\" would be consistently expressed with the syntax.\n> \"git commit -a\" would not mean \"--all\" anymore. Lastly, a distinction\n> would be made between \"--add\" and \"--update\":\n> - \"git commit -add\" would have the same semantics as \"git add\"\n\nThis is bollocks. git commit should commit things. We'll be in some \nserious trouble if \"git commit -a\" stops working the way it has and \nstarts just adding things to index.\n\n> - \"git commit --update\" on the other hand would only affect the files\n> already tracked\n>\n\nI fail to see what you're after with the changes propsed in this mail.\nIs there a use-case you've encountered where you wanted to do something \nthat wasn't possible, or easy enough, that made you post this?\n\nUnless it's a very, very good reason I most urgently think we're better \noff keeping the current \"git commit -a\" behaviour.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"295376","messageId":"7vzm9on7su.fsf@assigned-by-dhcp.cox.net","threadId":"43071","inReplyTo":"4582906A.7020204@op5.se","subject":"Re: [RFC] A unique way to express \"all\" (vs \"add vs \"update\") ?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-15T21:55:13Z","receivedAt":"2006-12-15T21:55:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n> Jerome Lovy wrote:\n> ...\n> But this isn't \"commit\" at all. It's \"git add\".\n>\n>> (This would allow the typical usage \"git commit -u .\" which is\n>> barely longer than the current \"git commit -a\")\n>>\n>> For interface completeness, \"git commit -u|--update \" could also\n>> exist but would probably be of no use.\n>>\n>> To sum up, \"all\" would be consistently expressed with the syntax.\n>> \"git commit -a\" would not mean \"--all\" anymore. Lastly, a distinction\n>> would be made between \"--add\" and \"--update\":\n>> - \"git commit -add\" would have the same semantics as \"git add\"\n>\n> This is bollocks. git commit should commit things. We'll be in some\n> serious trouble if \"git commit -a\" stops working the way it has and\n> starts just adding things to index.\n\nI agree everything you said in your response to Jerome, except\nfor one thing.\n\nWe might want to allow:\n\n\t$ git commit untracked.c tracked.c\n\nto internally 'git add' untracked files while making the commit.\n\nCurrently you would get:\n\n\t$ git commit untracked.c tracked.c\n error: pathspec 'untracked.c' did not match any file(s) known to git.\n Did you forget to 'git add'?\n\nwhich is usable, safe, and helpful, so changing it to\nautomatically including it would not help the end user that\nmuch and one could argue that it removes the safety which is a\nbad idea.\n\nSo, let's not do this; sorry for the noise.\n\n\n"},{"id":"297373","messageId":"87mz5o4v2v.wl%cworth@cworth.org","threadId":"43071","inReplyTo":"elu1cn$k3$1@sea.gmane.org","subject":"Re: [RFC] A unique way to express \"all\" (vs \"add vs \"update\") ?","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-12-15T23:07:20Z","receivedAt":"2006-12-15T23:07:20Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Fri, 15 Dec 2006 12:38:51 +0100, Jerome Lovy wrote:\n> While I am very happy with the refactorings undertaken with regard to\n> \"git add/git commit\" (both for UI and documentation), I am still a\n> little confused by the different ways I seem to find to express the idea\n> \"I want to add (sort of) all file contents\".\n\nI agree that there have been huge improvements---particularly in\ndocumentation. So thanks to everybody!\n\nHere's a simpler idea that might add the unification you're looking\nfor. How about a new option:\n\n\tgit add -a|--all\n\nThis would allow \"git commit -a|--all\" to be understood as a simple\nhelper for:\n\n\tgit add -a|--all\n\tgit commit\n\nThat kind of unification seems like it could be helpful while learning\nthings. And I believe I've even wanted to do the \"git add -a\"\noperation before, so I think it might be useful in its own right at\ntimes, (though I can't think of a good example of why at the moment,\nso perhaps its not that important).\n\n-Carl\n"},{"id":"294628","messageId":"45868003.3010803@brefemail.com","threadId":"43071","inReplyTo":"4582906A.7020204@op5.se","subject":"Re: [RFC] A unique way to express \"all\" (vs \"add vs \"update\") ?","fromName":"Jerome Lovy","fromEmail":"t2a2e9z8ncbs9qg@brefemail.com","sentAt":"2006-12-18T11:48:19Z","receivedAt":"2006-12-18T11:48:19Z","isPatch":false,"sender":{"key":"t2a2e9z8ncbs9qg@brefemail.com","avatar":null},"body":"Hi,\n\nAndreas Ericsson wrote:\n> Jerome Lovy wrote:\n>> While I am very happy with the refactorings undertaken with regard to\n>> \"git add/git commit\" (both for UI and documentation), I am still a\n>> little confused by the different ways I seem to find to express the idea\n>> \"I want to add (sort of) all file contents\".\n>>\n>> To be more specific, I find the following in the current documentation:\n>>\n>> git add \n>> \"adds content from all files under directory and its\n>> subdirectories.\"\n>> (as interpreted from the \"EXAMPLES\" section of the git-add\n>> man-page)\n>> (BTW, could this usage be documented in the SYNOPSIS and\n>> DESCRIPTION sections (admittedly at a 2nd rank after the\n>> currently documented usage) as well as in the EXAMPLES ?\n>> Besides this reference sections would probably include the\n>> / usage that I've not mentioned here for the sake\n>> of simplicity.)\n>> Moreover, the tutorial documents the typical usage \"git add .\"\n>>\n>> git commit -a|--all\n>> \"automatically stage files that have been modified and deleted,\n>> but new files you have not told git about are not affected.\"\n>>\n>> Granted, the latter semantics for \"all\" is not exactly the same as the\n>> former. Nonetheless, I think it would be very nice to only have to \n>> memorize one way to express \"all\".\n>>\n> \n> But the former isn't \"all\"; It's a specific directory, although \".\" \n> happens to *look* like \"all\", you can run \"git add .\" in a subdirectory \n> inside the repository and it won't mean \"all\" anymore. Likewise, you can \n> say \"git commit .\" from a subdirectory and have it commit all changes to \n> all tracked files under that directory.\nOK. For my information, are the following commands completely\nequivalent ?\n1)\tgit commit -a\n2)\t(cd `git-rev-parse --git-dir`/..; git commit .)\n\n> \n>> To this end, I would be very happy with the following:\n>> (X-mas is coming soon, isn't it ;-) )\n>>\n>> git add \n>> same semantics\n>>\n>> git commit -a|--add \n>> \"adds content from the specified files before committing\n>> (files that are already tracked have their current content\n>> staged)\"\n>>\n>> git commit -a|--add \n>> \"adds content from all files under directory and its\n>> subdirectories before committing\"\n>> (once again, for simplification of my explanations, I omit the\n>> / usage here)\n>>\n>> git commit -u|--update \n>> \"automatically stage files that have been modified and deleted\n>> under directory and its subdirectories, but new files you\n>> have not told git about are not affected.\"\n>> (once again, for simplification of my explanations, I omit the\n>> / usage here)\n>>\n> \n> But this isn't \"commit\" at all. It's \"git add\".\nOK. To faithfully follow the current existing description of\n'git commit -a', I should have indeed written:\ngit commit -u|--update \n \"_Tell the command to_ automatically stage files that have been\n modified and deleted under directory and its subdirectories,\n but new files you have not told git about are not affected.\"\n\n> \n>> (This would allow the typical usage \"git commit -u .\" which is\n>> barely longer than the current \"git commit -a\")\n>>\n>> For interface completeness, \"git commit -u|--update \" could also\n>> exist but would probably be of no use.\n>>\n>> To sum up, \"all\" would be consistently expressed with the syntax.\n>> \"git commit -a\" would not mean \"--all\" anymore. Lastly, a distinction\n>> would be made between \"--add\" and \"--update\":\n>> - \"git commit -add\" would have the same semantics as \"git add\"\n> \n> This is bollocks. git commit should commit things. We'll be in some \n> serious trouble if \"git commit -a\" stops working the way it has and \n> starts just adding things to index.\nOK. I obviously wasn't precise enough. Let me restate:\n- \"git commit -add\" would allow the same / parameter usage as \n\"git add\"\n\n> \n>> - \"git commit --update\" on the other hand would only affect the files\n>> already tracked\n>>\n> \n> I fail to see what you're after with the changes propsed in this mail.\n> Is there a use-case you've encountered where you wanted to do something \n> that wasn't possible, or easy enough, that made you post this?\nMy case is not that I've encountered something that wasn't possible or \neasy enough (everything is indeed possible with the right combination of \n\"git add\" and \"git commit\"), but rather that I candidly felt that \n\"--all\" is more difficult to understand/learn/memorize/teach than \nexpected since it doesn't really mean \"all\" (because it excludes \"new \nfiles you have not told git about\").\n\n> \n> Unless it's a very, very good reason I most urgently think we're better \n> off keeping the current \"git commit -a\" behaviour.\n> \n"},{"id":"295136","messageId":"45869FD6.3030104@brefemail.com","threadId":"43071","inReplyTo":"87mz5o4v2v.wl%cworth@cworth.org","subject":"Re: [RFC] A unique way to express \"all\" (vs \"add vs \"update\") ?","fromName":"Jerome Lovy","fromEmail":"t2a2e9z8ncbs9qg@brefemail.com","sentAt":"2006-12-18T14:04:06Z","receivedAt":"2006-12-18T14:04:06Z","isPatch":false,"sender":{"key":"t2a2e9z8ncbs9qg@brefemail.com","avatar":null},"body":"Carl Worth wrote:\n> On Fri, 15 Dec 2006 12:38:51 +0100, Jerome Lovy wrote:\n>> While I am very happy with the refactorings undertaken with regard to\n>> \"git add/git commit\" (both for UI and documentation), I am still a\n>> little confused by the different ways I seem to find to express the idea\n>> \"I want to add (sort of) all file contents\".\n> \n> I agree that there have been huge improvements---particularly in\n> documentation. So thanks to everybody!\n> \n> Here's a simpler idea that might add the unification you're looking\n> for. How about a new option:\n> \n> \tgit add -a|--all\n> \n> This would allow \"git commit -a|--all\" to be understood as a simple\n> helper for:\n> \n> \tgit add -a|--all\n> \tgit commit\n> \n> That kind of unification seems like it could be helpful while learning\n> things.\nExactly. I like it.\n\nNow, it underlines the fact that this \"--all\" should IMHO rather be\ncalled \"--all-known\" or the like - both for \"add\" and \"commit\" - but all\nthe same, I would be very happy with a more complete \"git add\" following\nyour proposed unification.\n\nJérôme\n"}]}