{"thread":{"id":"27125","subject":"Inconsistency with -a vs -A","startedAt":"2011-04-18T03:20:55Z","lastAt":"2011-04-18T15:04:13Z","messageCount":4,"participants":["Bradly Feeley","Michael J Gruber","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"166023","messageId":"loom.20110418T051443-551@post.gmane.org","threadId":"27125","inReplyTo":null,"subject":"Inconsistency with -a vs -A","fromName":"Bradly Feeley","fromEmail":"bradlyf@gmail.com","sentAt":"2011-04-18T03:20:55Z","receivedAt":"2011-04-18T03:20:55Z","isPatch":false,"sender":{"key":"bradlyf@gmail.com","avatar":null},"body":"I was curious if there was a reason that some command use -a and some command\nuse -A. For example, to view all branches the lowercase switch 'a' is used, but\nwhen staging all files with add an uppercase 'A'. Of course I always pick the\nwrong one when running either command. Is there a reason for the inconsistency?\nDo you think they should be made the same?\n\nThanks!\nBradly Feeley\n"},{"id":"166026","messageId":"4DABD971.20108@drmicha.warpmail.net","threadId":"27125","inReplyTo":"loom.20110418T051443-551@post.gmane.org","subject":"Re: Inconsistency with -a vs -A","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-04-18T06:25:53Z","receivedAt":"2011-04-18T06:25:53Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Bradly Feeley venit, vidit, dixit 18.04.2011 05:20:\n> I was curious if there was a reason that some command use -a and some command\n> use -A. For example, to view all branches the lowercase switch 'a' is used, but\n> when staging all files with add an uppercase 'A'. Of course I always pick the\n> wrong one when running either command. Is there a reason for the inconsistency?\n\nYes.\n\n> Do you think they should be made the same?\n\nYes, I do :) For more details on both \"yes\", see:\n\nhttp://permalink.gmane.org/gmane.comp.version-control.git/167907\n\nCheers,\nMichael\n"},{"id":"166030","messageId":"7vbp03ann1.fsf@alter.siamese.dyndns.org","threadId":"27125","inReplyTo":"loom.20110418T051443-551@post.gmane.org","subject":"Re: Inconsistency with -a vs -A","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-18T09:56:34Z","receivedAt":"2011-04-18T09:56:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bradly Feeley <bradlyf@gmail.com> writes:\n\n> I was curious if there was a reason that some command use -a and some command\n> use -A.\n\nIn the context of SCM, the word \"all\" is unfortunately ambiguous. In most\ncases, when you say \"all\", you do not mean everything under the sun, but\nonly mean the tracked subset of everything.\n\nFor example, \"commit -a\" only includes the paths that have been tracked,\nand grabs the up-to-date contents in them in your working tree. It does\nnot add paths that have been untracked to the set of tracked paths. This\nwas historically useful because we started out without a good .gitignore\nsupport and \"commit .\" is not \"everything\" when run from a subdirectory.\n\nAlso many commands (e.g. \"git diff\", \"git grep\") work on \"all tracked\"\nwhen you do not explicitly name what to operate on.  Even when you specify\nwhat subset to operate on, that subset is still taken from \"all tracked\",\nnot \"everything in the working tree\" (e.g. \"git grep -e frotz .\" does not\nlook into any untracked paths).\n\nWhen you think about \"tracked\" vs \"untracked\", you would realize that\n\"add\" is and has to be an oddball. It is the primary mechanism to start\ntracking hitherto untracked paths.  For this reason, \"git add .\" has to\nlook at untracked paths and add them (contrast this with the \"git grep\"\nexample above).\n\nWe named the \"update contents for all tracked paths\" option \"-u\", avoiding\nto say \"-a\" on purpose, because \"all\" is an ambiguous word, especially in\nthe context of \"git add\" command.  It perhaps was being overly cautious in\nhindsight.\n\nOne important case to think about is that \"git commit -a\". Most commands\nlimit the set of paths they operate on from all tracked paths, and this\ncommand has to mean \"take the up-to-date contents from all tracked files\nand make a commit\".  So does \"git commit .\" run from the top-level of the\ntree.\n\nNow, what if you have a bunch of hitherto untracked paths, have a well\nmaintained .gitignore file, want to add and commit them, and want to be\nlazy (i.e. you hate that \"git add . && git commit\" are two commands)?\nThere needs a way to say \"everything under the sun\" to please such people.\n\nThat is where \"git commit -A\" came from. \"add -A\" is an option that is\nunnecessary (\"git add .\" would do just fine), but was added to give a\nwarm-fuzzy feel of consistency between \"commit\" and \"add\", in preparation\nof the planned addition of \"git commit -A\" that didn't happen.\n\nThe only uppercase \"-A\" I am aware of are these two, and both are about\n\"everything under the sun\", which is a special case in the context of SCM.\nAll the other usual \"all\" options are spelled \"-a\".\n\nI think we could give \"add -a\" as a synonym to \"add -u\", which would be a\nsafe addition that would not break any existing user, if we wanted to be\npicky and really make things more consistent.\n\nAlso in the longer term, I suspect we probably should deprecate \"add -A\"\nas a failed experiment, if we are not going to do \"commit -A\" after all.\n\"add .\" and \"add :/\" (from a subdirectory) would be much less ambiguous,\nand it will get rid of the only instance of \"-A\" that means something\nslightly different from the usual \"all\".\n"},{"id":"166036","messageId":"7v7hara9ea.fsf@alter.siamese.dyndns.org","threadId":"27125","inReplyTo":"7vbp03ann1.fsf@alter.siamese.dyndns.org","subject":"Re: Inconsistency with -a vs -A","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-18T15:04:13Z","receivedAt":"2011-04-18T15:04:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> The only uppercase \"-A\" I am aware of are these two, and both are about\n> \"everything under the sun\", which is a special case in the context of SCM.\n> All the other usual \"all\" options are spelled \"-a\".\n>\n> I think we could give \"add -a\" as a synonym to \"add -u\", which would be a\n> safe addition that would not break any existing user, if we wanted to be\n> picky and really make things more consistent.\n>\n> Also in the longer term, I suspect we probably should deprecate \"add -A\"\n> as a failed experiment, if we are not going to do \"commit -A\" after all.\n> \"add .\" and \"add :/\" (from a subdirectory) would be much less ambiguous,\n> and it will get rid of the only instance of \"-A\" that means something\n> slightly different from the usual \"all\".\n\nThe last paragraph is really \"in the _longer_ term\".  Two things need to\nhappen before we get there:\n\n - we need to teach \"add .\" or with any pathspec to do what the current\n   \"-A\" with the same pathspec does implicitly, while keeping \"add\"\n   without any pathspec a no-op.\n\n - \":/\" (from root, whole tree) needs to be added.  We already know how\n   that pathspec will behave and how to implement it.\n\nThe former may need a bit of thought and discussion, but I personally\nthink that \"git add\" with pathspec should notice deletion of tracked\npaths.  It may have been Ok back when \"git add $path\" was only for adding\nnew paths, but we have changed from that semantics a long time ago and the\ncommand deals with both tracked and untracked paths.  It does not make\nmuch sense to special case tracked but removed paths anymore [*1*]\n\nThe latter we know we will have in a release or two.\n\n\n[Footnote]\n\n* The code does not do any special casing at the design level, but they\nfall within the cracks of the implementation.\n"}]}