{"thread":{"id":"26489","subject":"Consistent terminology: cached/staged/index","startedAt":"2011-02-13T19:20:56Z","lastAt":"2011-03-06T12:44:43Z","messageCount":65,"participants":["Piotr Krukowiecki","Jonathan Nieder","Junio C Hamano","Miles Bader","Pete Harlan","Johannes Sixt","Michael J Gruber","Nguyen Thai Ngoc Duy","Felipe Contreras","Jakub Narebski","Drew Northup","Jeff King","Phil Hord","Aghiles","Jon Seymour","Victor Engmark","David","Matthieu Moy","Alexey Feldgendler","Alexei Sholik"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"161011","messageId":"AANLkTi=9OWqz66Ab6O9tc4eYSrhZZ1YC_+ta9sutAn30@mail.gmail.com","threadId":"26489","inReplyTo":null,"subject":"Consistent terminology: cached/staged/index","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki.news@gmail.com","sentAt":"2011-02-13T19:20:56Z","receivedAt":"2011-02-13T19:20:56Z","isPatch":false,"sender":{"key":"piotr.krukowiecki.news@gmail.com","avatar":null},"body":"Hi,\n\nis there a plan for using one term instead of three to describe\noperations on index?\n\n>From quick search:\n* \"add\" mentions index and staging\n* all commands except one take \"--cached\" only\n* \"diff\" also takes \"--staged\"\n* \"diff\" mentions index and staging\n* \"log\" mentions index\n* \"reset\" mentions index\n\n\n-- \nPiotrek\n"},{"id":"161014","messageId":"20110213193738.GA26868@elie","threadId":"26489","inReplyTo":"AANLkTi=9OWqz66Ab6O9tc4eYSrhZZ1YC_+ta9sutAn30@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-13T19:37:38Z","receivedAt":"2011-02-13T19:37:38Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Piotr Krukowiecki wrote:\n\n> is there a plan for using one term instead of three to describe\n> operations on index?\n\nNo. But ideas (and especially patches) for improving the\ndocumentation would be appreciated.\n\n> From quick search:\n> * \"add\" mentions index and staging\n> * all commands except one take \"--cached\" only\n> * \"diff\" also takes \"--staged\"\n> * \"diff\" mentions index and staging\n> * \"log\" mentions index\n> * \"reset\" mentions index\n\nIf I understand correctly, the intended semantics are:\n\n--index versus --cached\n~~~~~~~~~~~~~~~~~~~~~~~\nThe place where changes for the next commit get registered is called\nthe \"index file\".\n\nCommands that pay attention to the registered content of files rather\nthan the copies in the work tree use the option name \"--cached\". This\nis mostly for historical reasons --- early on, it was not obvious that\nmaking the index not match the worktree was going to be useful.\n\nCommands that update the registered content of files in addition to\nthe worktree use the option name \"--index\".\n\n--staged\n~~~~~~~~\ndiff takes --staged, but that is only to support some people's habits.\n\nThe term \"to stage\" is generally an abbreviation for \"to stage in the\nindex\", meaning \"to mark for use in the next commit\". It is used to\npaint a certain picture of the process in which one makes sure\neverything is just right before committing to the result.\n\nHope that helps,\nJonathan\n"},{"id":"161015","messageId":"7v8vxjwnhj.fsf@alter.siamese.dyndns.org","threadId":"26489","inReplyTo":"20110213193738.GA26868@elie","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-13T22:58:32Z","receivedAt":"2011-02-13T22:58:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> If I understand correctly, the intended semantics are:\n>\n> --index versus --cached\n> ~~~~~~~~~~~~~~~~~~~~~~~\n> The place where changes for the next commit get registered is called\n> the \"index file\".\n>\n> Commands that pay attention to the registered content of files rather\n> than the copies in the work tree use the option name \"--cached\". This\n> is mostly for historical reasons --- early on, it was not obvious that\n> making the index not match the worktree was going to be useful.\n>\n> Commands that update the registered content of files in addition to\n> the worktree use the option name \"--index\".\n\nMostly correct, except the \"early on, it was not obvious\" part. It was\nvery obvious from the early days that unlike \"cvs commit\" or \"svn commit\"\nit was very useful that you can trust \"git commit\", after preparing the\nindex with what is and isn't to be included in the commit, won't pick up\ndebugging cruft you keep around in the working tree.\n\n\"cache\" was an old name (and still established name in-use in the code)\nfor the index. Some commands make sense to affect both the index and the\nworking tree (e.g. \"apply\") and you give --index to mean \"both index and\nthe working tree\" while some other operating modes that make sense only to\nlook at the index, ignoring the potential difference between the working\ntree and the index (e.g. again \"apply\"), iow, taking only the cached\nchanges into account, are invoked with --cached to mean \"look only at what\nis recorded in the index\".\n\nSome people may find it a good idea to introduce new synonyms --index-only\nvs --index-and-working-tree. I personally am not opposed to such a change,\nas long as traditional --cached vs --index will keep working for people\nwho already learned the difference. These hypothetical new synonyms would\nbe more descriptive; the necessity to differenciate the two concepts the\ntwo options --cached vs --index try to tell apart is very real, but it was\na hack to use these two particular words --cached vs --index to do so\nwithout trying harder to come up with better words.\n\n\n> --staged\n> ~~~~~~~~\n> diff takes --staged, but that is only to support some people's habits.\n\nThis one actually needs more historical background to understand why it is\nthere, as the synonym is not necessary to understand how git works.\n\nOriginally, the way to say \"what is in the current working tree for this\npath is what I want to have in the next commit\" was \"update-index\". \"What\nI want to have in the next commit\" is \"the index\", and the operation is\nabout \"updating\" that \"What I want to have...\", so the name of the command\nmade perfect sense. \"update-index\" had a safety valve to prevent careless\ninvocation of \"update-index *\" to add all the cruft in the working tree\n(there wasn't any .gitignore mechanism in the Porcelain nor in the\nplumbing) and by default affected only the paths that are already in the\nindex. You needed to say \"update-index --add\" to include paths that are\nnot in the index.\n\nA more user friendly Porcelain \"git add\" was later implemented in terms of\n\"update-index --add\", but originally it was to add new paths; updating the\ncontents was still done via \"update-index\" interface.\n\nThis changed in v1.5.0, around the beginning of 2007. Nicolas Pitre among\nothers realized that git is about tracking contents, not paths, which\nmeant that \"make the content in the working tree at this moment appear in\nthe next commit\" is equivalent to saying \"add this _content_ to the set of\ncontents that make up the next commit\". \"git add\" learned to accept both\nnew paths that were not in the index so far and also paths known to the\nindex that had old contents for them.\n\nBefore v1.5.0, we explained the concept as \"we update the set of contents\nto be in the next commit\" (hence \"update-index\"); since v1.5.0, we explain\nthe concept as \"we add what's in these paths to the set of contents to be\nin the next commit\" (hence \"add\").\n\nNotice that there is no need for a new terminology \"staged\" in the above\ndescription?\n\nThe semantics of the index didn't change ever since, modulo small tweaks\nlike \"add -i\" (I borrowed it from Darcs) that allows us to say \"add parts\nof the changed content\" instead of the \"what's in the file as a whole\nright now\" were added; these small tweaks didn't introduce any conceptual\nchange.\n\nThe term \"stage\" comes from \"staging area\", a term people used to explain\nthe concept of the index by saying \"The index holds set of contents to be\nmade into the next commit; it is _like_ the staging area\".\n\nMy feeling is that \"to stage\" is primarily used, outside \"git\" circle, as\na logistics term. If you find it easier to visualize the concept of the\nindex with \"staging area\" (\"an area where troops and equipment in transit\nare assembled before a military operation\", you may find it easier to say\n\"stage this path ('git add path')\", instead of \"adding to the set of\ncontents...\".\n\nAlthough I tried to use the word myself in earlier days, I have never felt\nthat \"staging area\" is a very widely known term for non-native speakers of\nEnglish, and personally have tended to avoid using it. I find \"adding to\nthe set of contents...\" somewhat easier to understand regardless of your\nlanguage background, but it may be just me who is not a native speaker.\n\nIn short, \"stage\" is an unessential synonym that came much later, and that\nis why we avoid advertising it even in the document of \"git diff\" too\nheavily. Unlike the hypothetical --index-only synonym for --cached I\nmentioned earlier that adds real value by being more descriptive, \"staged\"\ndoes not add much value over what it tried to replace.\n"},{"id":"161021","messageId":"87k4h34bhj.fsf@catnip.gol.com","threadId":"26489","inReplyTo":"7v8vxjwnhj.fsf@alter.siamese.dyndns.org","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2011-02-14T02:05:12Z","receivedAt":"2011-02-14T02:05:12Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Junio C Hamano writes:\n> Some people may find it a good idea to introduce new synonyms --index-only\n> vs --index-and-working-tree. I personally am not opposed to such a change,\n\nThose are so long that nobody will ever use them though...\n\nOne of my big peeves is simply that \"git diff --cached\" is too long, as\nit's an extremely common command (the name isn't exactly intuitive, even\nafter many years of use, but it's just one of those things you\nmemorize).\n\nIs there a reason a short version of --cached couldn't be added to\ngit-diff...? E.g. \"git diff -c\"?\n\nThanks,\n\n-Miles\n\n-- \nOcean, n. A body of water covering seven-tenths of a world designed for Man -\nwho has no gills.\n"},{"id":"161022","messageId":"4D589CE0.7020203@pcharlan.com","threadId":"26489","inReplyTo":"7v8vxjwnhj.fsf@alter.siamese.dyndns.org","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Pete Harlan","fromEmail":"pgit@pcharlan.com","sentAt":"2011-02-14T03:09:20Z","receivedAt":"2011-02-14T03:09:20Z","isPatch":false,"sender":{"key":"pgit@pcharlan.com","avatar":null},"body":"On 02/13/2011 02:58 PM, Junio C Hamano wrote:\n>> --staged\n>> ~~~~~~~~\n>> diff takes --staged, but that is only to support some people's habits.\n> The term \"stage\" comes from \"staging area\", a term people used to explain\n> the concept of the index by saying \"The index holds set of contents to be\n> made into the next commit; it is _like_ the staging area\".\n> \n> My feeling is that \"to stage\" is primarily used, outside \"git\" circle, as\n> a logistics term. If you find it easier to visualize the concept of the\n> index with \"staging area\" (\"an area where troops and equipment in transit\n> are assembled before a military operation\", you may find it easier to say\n> \"stage this path ('git add path')\", instead of \"adding to the set of\n> contents...\".\n\nFWIW, when teaching Git I have found that users immediately understand\n\"staging area\", while \"index\" and \"cache\" confuse them.\n\n\"Index\" means to them a numerical index into a data structure.\n\"Cache\" is a local copy of something that exists remotely. Neither\nword describes the concept correctly from a user's perspective.\n\nI learned long ago to type \"index\" and \"cached\", but when talking (and\nthinking) about Git I find \"the staging area\" gets the point across\nvery clearly and moves Git from interesting techie-tool to\nworld-dominating SCM territory. I'm surprised that that experience\nisn't universal.\n\n--Pete\n"},{"id":"161025","messageId":"7vr5bbupj4.fsf@alter.siamese.dyndns.org","threadId":"26489","inReplyTo":"87k4h34bhj.fsf@catnip.gol.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-14T05:57:19Z","receivedAt":"2011-02-14T05:57:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Miles Bader writes:\n\n> Is there a reason a short version of --cached couldn't be added to\n> git-diff...? E.g. \"git diff -c\"?\n\nI'd suspect that we would like to keep the door open for \"diff -c\" to do\nwhat the users naturally expect, namely, to produce a patch in the copied\ncontext format.\n\nI don't immediately plan to do so myself, though.\n"},{"id":"161027","messageId":"AANLkTi=PDhVgpTeFjTxFuVJGbAKTHzHhsNVcquqSD3Qq@mail.gmail.com","threadId":"26489","inReplyTo":"7vr5bbupj4.fsf@alter.siamese.dyndns.org","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2011-02-14T06:27:55Z","receivedAt":"2011-02-14T06:27:55Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"On Mon, Feb 14, 2011 at 5:57 AM, Junio C Hamano wrote:\n>> Is there a reason a short version of --cached couldn't be added to\n>> git-diff...?  E.g. \"git diff -c\"?\n>\n> I'd suspect that we would like to keep the door open for \"diff -c\" to do\n> what the users naturally expect, namely, to produce a patch in the copied\n> context format.\n\nhmm\n\n\"git diff -s\" ? ... since --staged is an alias for --cached :)\n\n-miles\n\n-- \nCat is power.  Cat is peace.\n"},{"id":"161028","messageId":"4D58D2DF.1050205@viscovery.net","threadId":"26489","inReplyTo":"AANLkTi=PDhVgpTeFjTxFuVJGbAKTHzHhsNVcquqSD3Qq@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2011-02-14T06:59:43Z","receivedAt":"2011-02-14T06:59:43Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 2/14/2011 7:27, schrieb Miles Bader:\n> \"git diff -s\" ? ... since --staged is an alias for --cached :)\n\ngit config --global alias.diffc \"diff --cached\"\n\n?\n\n-- Hannes\n"},{"id":"161029","messageId":"AANLkTikTfyHBOvQmjhT8yTziL4R67+AAk0O-Nk1tBSaL@mail.gmail.com","threadId":"26489","inReplyTo":"4D58D2DF.1050205@viscovery.net","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2011-02-14T07:07:49Z","receivedAt":"2011-02-14T07:07:49Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"On Mon, Feb 14, 2011 at 6:59 AM, Johannes Sixt wrote:\n> Am 2/14/2011 7:27, schrieb Miles Bader:\n>> \"git diff -s\"  ? ... since --staged is an alias for --cached :)\n>\n> git config --global alias.diffc \"diff --cached\"\n\n\"Git should be convenient by default (for commonly used operations)\"\n\n-miles\n\n-- \nCat is power.  Cat is peace.\n"},{"id":"161038","messageId":"4D5906FD.7030502@drmicha.warpmail.net","threadId":"26489","inReplyTo":"AANLkTikTfyHBOvQmjhT8yTziL4R67+AAk0O-Nk1tBSaL@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-02-14T10:42:05Z","receivedAt":"2011-02-14T10:42:05Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Miles Bader venit, vidit, dixit 14.02.2011 08:07:\n> On Mon, Feb 14, 2011 at 6:59 AM, Johannes Sixt wrote:\n>> Am 2/14/2011 7:27, schrieb Miles Bader:\n>>> \"git diff -s\" ? ... since --staged is an alias for --cached :)\n>>\n>> git config --global alias.diffc \"diff --cached\"\n> \n> \"Git should be convenient by default (for commonly used operations)\"\n> \n> -miles\n> \n\ngit diff --ca\n\n;)\n\nAt least if \"by default\" includes using the default bash completion by\ndefault.\n\nShort options should really not be \"wasted\" easily. \"-s\" named after \"to\nstage\" is really problematic, as outlined in this thread. It's mainly\nused (and has been introduced, I think) by \"the other git community\", so\nto say. I feel that sticking to established terminology (esp. that used\nin man pages and command messages) is more helpful for newbies. That\ndoes not exclude using new terms for explaining that terminology, of course.\n\nThe term \"stage\" is in git's documentation all over the place - and\ndenotes the different versions of a blob involved in a merge.\nAdmittedly, that's something recorded in the index.\n\nFull disclaimer: I have an alias \"staged\" for \"diff --cached\" myself...\n\nMichael\n"},{"id":"161039","messageId":"buod3muswq7.fsf@dhlpc061.dev.necel.com","threadId":"26489","inReplyTo":"4D5906FD.7030502@drmicha.warpmail.net","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2011-02-14T11:04:48Z","receivedAt":"2011-02-14T11:04:48Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Michael J Gruber writes:\n> Short options should really not be \"wasted\" easily. \"-s\" named after \"to\n> stage\" is really problematic, as outlined in this thread.\n\nEr, but the point is that this is _such_ a common operation, that a\nshort option for it would not be \"wasted\" at all. [The whole concept of\n\"wasting\" short options doesn't even make sense unless you're willing to\nthen use the resulting \"preserved\" options eventually...]\n\nIndeed it seems a little weird that there's not one for this already,\ngiven how common short options are in git generally, often for far less\nuseful options than --cached/--staged; I can only guess that the reason\nis basically historical accident.\n\nAs for the exact letter chosen, \"-s\" seems perfectly fine to me. Short\noptions do not need to be \"perfect\" to be useful, and the connection\nwith --staged is a perfectly plausible memory aid for that short period\nduring which people memorize them.\n\n-Miles\n\n-- \nThe secret to creativity is knowing how to hide your sources.\n --Albert Einstein\n"},{"id":"161043","messageId":"AANLkTi=RcJfEGv966VCrOMPE640xyyw1wEFFkdA9fFWq@mail.gmail.com","threadId":"26489","inReplyTo":"4D5906FD.7030502@drmicha.warpmail.net","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-14T13:14:55Z","receivedAt":"2011-02-14T13:14:55Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Feb 14, 2011 at 5:42 PM, Michael J Gruber\n wrote:\n> Full disclaimer: I have an alias \"staged\" for \"diff --cached\" myself...\n\nBe careful with your fingers. There's a command named \"git stage\".\n-- \nDuy\n"},{"id":"161045","messageId":"4D59316E.5090203@drmicha.warpmail.net","threadId":"26489","inReplyTo":"AANLkTi=RcJfEGv966VCrOMPE640xyyw1wEFFkdA9fFWq@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-02-14T13:43:10Z","receivedAt":"2011-02-14T13:43:10Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Nguyen Thai Ngoc Duy venit, vidit, dixit 14.02.2011 14:14:\n> On Mon, Feb 14, 2011 at 5:42 PM, Michael J Gruber\n> wrote:\n>> Full disclaimer: I have an alias \"staged\" for \"diff --cached\" myself...\n> \n> Be careful with your fingers. There's a command named \"git stage\".\n\nI know. Can we remove it as part of 1.8.0? It's our only builtin alias.\n\nMichael\n"},{"id":"161048","messageId":"AANLkTimh2E5i5Jgs2z3t-ai1pVkiNs5VdiP7T4pS_fzL@mail.gmail.com","threadId":"26489","inReplyTo":"4D59316E.5090203@drmicha.warpmail.net","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-14T13:57:20Z","receivedAt":"2011-02-14T13:57:20Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Feb 14, 2011 at 8:43 PM, Michael J Gruber\n wrote:\n> Nguyen Thai Ngoc Duy venit, vidit, dixit 14.02.2011 14:14:\n>> On Mon, Feb 14, 2011 at 5:42 PM, Michael J Gruber\n>> wrote:\n>>> Full disclaimer: I have an alias \"staged\" for \"diff --cached\" myself...\n>>\n>> Be careful with your fingers. There's a command named \"git stage\".\n>\n> I know. Can we remove it as part of 1.8.0? It's our only builtin alias.\n\nIt's out in the field. I don't think we can just simply remove it.\nIt'd be nice though to have a mechanism to override (or even remove,\nin your case) builtin commands, or at least porcelain ones. A feature\nwith a big \"your feet is expected to be shot by yourself\" warning.\n-- \nDuy\n"},{"id":"161050","messageId":"AANLkTikWsNgL6dSHueGCXw0jH4hnvai81X=EQERuw3Qi@mail.gmail.com","threadId":"26489","inReplyTo":"4D59316E.5090203@drmicha.warpmail.net","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-02-14T14:17:19Z","receivedAt":"2011-02-14T14:17:19Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Feb 14, 2011 at 3:43 PM, Michael J Gruber\n wrote:\n> Nguyen Thai Ngoc Duy venit, vidit, dixit 14.02.2011 14:14:\n>> On Mon, Feb 14, 2011 at 5:42 PM, Michael J Gruber\n>> wrote:\n>>> Full disclaimer: I have an alias \"staged\" for \"diff --cached\" myself...\n>>\n>> Be careful with your fingers. There's a command named \"git stage\".\n>\n> I know. Can we remove it as part of 1.8.0? It's our only builtin alias.\n\nI have proposed before to extend 'git stage', so you can do 'git stage\ndiff', or if you alias 'git stage' to 'git s', just 'git s diff'. This\nwould not conflict with the old behavior of 'git stage $file'.\n\ncase \"$1\" in\nadd)\n shift\n git add $@\n ;;\nrm)\n shift\n git rm --cached $@\n ;;\ndiff)\n shift\n git diff --cached $@\n ;;\nimport)\n shift\n git ls-files --modified --others --exclude-standard -z $@ | \\\n git update-index --add --remove -z --stdin\n ;;\nls)\n shift\n git ls-files --stage $@\n ;;\n*)\n git add $@\n ;;\nesac\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"161051","messageId":"AANLkTi=N7N31D09YoRQsGTntspUfZRjfNHQtVpUfRus_@mail.gmail.com","threadId":"26489","inReplyTo":"AANLkTikWsNgL6dSHueGCXw0jH4hnvai81X=EQERuw3Qi@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-14T14:21:47Z","receivedAt":"2011-02-14T14:21:47Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Feb 14, 2011 at 9:17 PM, Felipe Contreras\n wrote:\n> On Mon, Feb 14, 2011 at 3:43 PM, Michael J Gruber\n> wrote:\n>> Nguyen Thai Ngoc Duy venit, vidit, dixit 14.02.2011 14:14:\n>>> On Mon, Feb 14, 2011 at 5:42 PM, Michael J Gruber\n>>> wrote:\n>>>> Full disclaimer: I have an alias \"staged\" for \"diff --cached\" myself...\n>>>\n>>> Be careful with your fingers. There's a command named \"git stage\".\n>>\n>> I know. Can we remove it as part of 1.8.0? It's our only builtin alias.\n>\n> I have proposed before to extend 'git stage', so you can do 'git stage\n> diff', or if you alias 'git stage' to 'git s', just 'git s diff'. This\n> would not conflict with the old behavior of 'git stage $file'.\n\nIt does. What if I want to stage a file named \"add\", \"rm\" or \"diff\"?\n-- \nDuy\n"},{"id":"161052","messageId":"m3ipwm8yv0.fsf@localhost.localdomain","threadId":"26489","inReplyTo":"AANLkTi=N7N31D09YoRQsGTntspUfZRjfNHQtVpUfRus_@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-02-14T14:40:23Z","receivedAt":"2011-02-14T14:40:23Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nguyen Thai Ngoc Duy writes:\n> On Mon, Feb 14, 2011 at 9:17 PM, Felipe Contreras\n> wrote:\n>> On Mon, Feb 14, 2011 at 3:43 PM, Michael J Gruber\n>> wrote:\n>>> Nguyen Thai Ngoc Duy venit, vidit, dixit 14.02.2011 14:14:\n>>>> On Mon, Feb 14, 2011 at 5:42 PM, Michael J Gruber\n>>>> wrote:\n\n>>>>> Full disclaimer: I have an alias \"staged\" for \"diff --cached\" myself...\n>>>>\n>>>> Be careful with your fingers. There's a command named \"git stage\".\n>>>\n>>> I know. Can we remove it as part of 1.8.0? It's our only builtin alias.\n>>\n>> I have proposed before to extend 'git stage', so you can do 'git stage\n>> diff', or if you alias 'git stage' to 'git s', just 'git s diff'. This\n>> would not conflict with the old behavior of 'git stage $file'.\n> \n> It does. What if I want to stage a file named \"add\", \"rm\" or \"diff\"?\n\nThen you would use\n\n $ git stage ./diff\n\nor\n\n $ git stage -- diff\n\n(or even \"git add diff\" ;-)).\n\nP.S. I haven't checked that above work...\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"161064","messageId":"4D594911.40409@drmicha.warpmail.net","threadId":"26489","inReplyTo":"AANLkTikWsNgL6dSHueGCXw0jH4hnvai81X=EQERuw3Qi@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-02-14T15:24:01Z","receivedAt":"2011-02-14T15:24:01Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Felipe Contreras venit, vidit, dixit 14.02.2011 15:17:\n> On Mon, Feb 14, 2011 at 3:43 PM, Michael J Gruber\n> wrote:\n>> Nguyen Thai Ngoc Duy venit, vidit, dixit 14.02.2011 14:14:\n>>> On Mon, Feb 14, 2011 at 5:42 PM, Michael J Gruber\n>>> wrote:\n>>>> Full disclaimer: I have an alias \"staged\" for \"diff --cached\" myself...\n>>>\n>>> Be careful with your fingers. There's a command named \"git stage\".\n>>\n>> I know. Can we remove it as part of 1.8.0? It's our only builtin alias.\n> \n> I have proposed before to extend 'git stage', so you can do 'git stage\n> diff', or if you alias 'git stage' to 'git s', just 'git s diff'. This\n> would not conflict with the old behavior of 'git stage $file'.\n> \n> case \"$1\" in\n> add)\n> shift\n> git add $@\n> ;;\n> rm)\n> shift\n> git rm --cached $@\n> ;;\n> diff)\n> shift\n> git diff --cached $@\n> ;;\n> import)\n> shift\n> git ls-files --modified --others --exclude-standard -z $@ | \\\n> git update-index --add --remove -z --stdin\n> ;;\n> ls)\n> shift\n> git ls-files --stage $@\n> ;;\n> *)\n> git add $@\n> ;;\n> esac\n> \n> Cheers.\n> \n\nIn principle I like this a lot: a set of commands operating on/with the\nstage/index/cache consistently. It think it's similar in (good) spirit\nto our earlier attempts at INDEX and WORKTREE pseudo-revs, trying to\ngive that somewhat nebulous (for noobs) index a more concrete\n\"appearance\", not hidden away in options (--index, --cached) and\ndefaults (diff against index by default).\n\nIn our case, however, I think the design principle deviates from our\ncommon form:\n\ngit foo bar\n\nusually means \"do foo\" to \"bar\", as most of our common commands are\nverbs (being applied to the object \"bar\"). When it comes to subcommands\nwe do have inconsistencies already (double-dashed vs. undashed, e.g.),\nbut I'd prefer fewer ;)\n\nMichael\n"},{"id":"161066","messageId":"AANLkTi=cvObd83_5qiUxLKmVxiTMP2kgMfXaRb3uo4YY@mail.gmail.com","threadId":"26489","inReplyTo":"4D594911.40409@drmicha.warpmail.net","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-02-14T16:00:59Z","receivedAt":"2011-02-14T16:00:59Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Feb 14, 2011 at 5:24 PM, Michael J Gruber\n wrote:\n> Felipe Contreras venit, vidit, dixit 14.02.2011 15:17:\n>> On Mon, Feb 14, 2011 at 3:43 PM, Michael J Gruber\n>> wrote:\n>>> Nguyen Thai Ngoc Duy venit, vidit, dixit 14.02.2011 14:14:\n>>>> On Mon, Feb 14, 2011 at 5:42 PM, Michael J Gruber\n>>>> wrote:\n>>>>> Full disclaimer: I have an alias \"staged\" for \"diff --cached\" myself...\n>>>>\n>>>> Be careful with your fingers. There's a command named \"git stage\".\n>>>\n>>> I know. Can we remove it as part of 1.8.0? It's our only builtin alias.\n>>\n>> I have proposed before to extend 'git stage', so you can do 'git stage\n>> diff', or if you alias 'git stage' to 'git s', just 'git s diff'. This\n>> would not conflict with the old behavior of 'git stage $file'.\n\n[...]\n\n> In principle I like this a lot: a set of commands operating on/with the\n> stage/index/cache consistently. It think it's similar in (good) spirit\n> to our earlier attempts at INDEX and WORKTREE pseudo-revs, trying to\n> give that somewhat nebulous (for noobs) index a more concrete\n> \"appearance\", not hidden away in options (--index, --cached) and\n> defaults (diff against index by default).\n>\n> In our case, however, I think the design principle deviates from our\n> common form:\n>\n> git foo bar\n>\n> usually means \"do foo\" to \"bar\", as most of our common commands are\n> verbs (being applied to the object \"bar\"). When it comes to subcommands\n> we do have inconsistencies already (double-dashed vs. undashed, e.g.),\n> but I'd prefer fewer ;)\n\nExcept 'git branch', 'git tag', 'git remote', 'git stash', and 'git\nsubmodule'. In fact, every logical object in git seems to have their\nown command, except the stage.\n\n-- \nFelipe Contreras\n"},{"id":"161067","messageId":"4D59528F.6030202@drmicha.warpmail.net","threadId":"26489","inReplyTo":"AANLkTi=cvObd83_5qiUxLKmVxiTMP2kgMfXaRb3uo4YY@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-02-14T16:04:31Z","receivedAt":"2011-02-14T16:04:31Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Felipe Contreras venit, vidit, dixit 14.02.2011 17:00:\n> On Mon, Feb 14, 2011 at 5:24 PM, Michael J Gruber\n> wrote:\n>> Felipe Contreras venit, vidit, dixit 14.02.2011 15:17:\n>>> On Mon, Feb 14, 2011 at 3:43 PM, Michael J Gruber\n>>> wrote:\n>>>> Nguyen Thai Ngoc Duy venit, vidit, dixit 14.02.2011 14:14:\n>>>>> On Mon, Feb 14, 2011 at 5:42 PM, Michael J Gruber\n>>>>> wrote:\n>>>>>> Full disclaimer: I have an alias \"staged\" for \"diff --cached\" myself...\n>>>>>\n>>>>> Be careful with your fingers. There's a command named \"git stage\".\n>>>>\n>>>> I know. Can we remove it as part of 1.8.0? It's our only builtin alias.\n>>>\n>>> I have proposed before to extend 'git stage', so you can do 'git stage\n>>> diff', or if you alias 'git stage' to 'git s', just 'git s diff'. This\n>>> would not conflict with the old behavior of 'git stage $file'.\n> \n> [...]\n> \n>> In principle I like this a lot: a set of commands operating on/with the\n>> stage/index/cache consistently. It think it's similar in (good) spirit\n>> to our earlier attempts at INDEX and WORKTREE pseudo-revs, trying to\n>> give that somewhat nebulous (for noobs) index a more concrete\n>> \"appearance\", not hidden away in options (--index, --cached) and\n>> defaults (diff against index by default).\n>>\n>> In our case, however, I think the design principle deviates from our\n>> common form:\n>>\n>> git foo bar\n>>\n>> usually means \"do foo\" to \"bar\", as most of our common commands are\n>> verbs (being applied to the object \"bar\"). When it comes to subcommands\n>> we do have inconsistencies already (double-dashed vs. undashed, e.g.),\n>> but I'd prefer fewer ;)\n> \n> Except 'git branch', 'git tag', 'git remote', 'git stash', and 'git\n> submodule'. In fact, every logical object in git seems to have their\n> own command, except the stage.\n> \n\nYes, remote, stash and submodule are the ones with the different\nsubcommand handling I mentioned: the subcommand is the verb, and\nspecified undashed.\n\nWe have other commands with double-dashed (i.e. option) subcommands,\nsuch as \"brach --set-upstream\", and others single-dashed, such as \"tag -v\".\n\nNote that branch, tag and stash are verbs as well as nouns.\n\nI just think that \"git verb object\" is the more prevalent order, so that\nwe should move in that direction if we want make things better. Other\nthan that I would have no objection against \"git object verb\".\n\nMichael\n"},{"id":"161068","messageId":"AANLkTi=D19oucaPu6rZQeVjLetgY+s5_-q+n1Lb4oijo@mail.gmail.com","threadId":"26489","inReplyTo":"4D59528F.6030202@drmicha.warpmail.net","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-02-14T16:27:30Z","receivedAt":"2011-02-14T16:27:30Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Feb 14, 2011 at 6:04 PM, Michael J Gruber\n wrote:\n> Felipe Contreras venit, vidit, dixit 14.02.2011 17:00:\n>> Except 'git branch', 'git tag', 'git remote', 'git stash', and 'git\n>> submodule'. In fact, every logical object in git seems to have their\n>> own command, except the stage.\n>\n> Yes, remote, stash and submodule are the ones with the different\n> subcommand handling I mentioned: the subcommand is the verb, and\n> specified undashed.\n>\n> We have other commands with double-dashed (i.e. option) subcommands,\n> such as \"brach --set-upstream\", and others single-dashed, such as \"tag -v\".\n>\n> Note that branch, tag and stash are verbs as well as nouns.\n\nSo is stage.\n\n-- \nFelipe Contreras\n"},{"id":"161072","messageId":"7vtyg6tu9e.fsf@alter.siamese.dyndns.org","threadId":"26489","inReplyTo":"buod3muswq7.fsf@dhlpc061.dev.necel.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-14T17:12:45Z","receivedAt":"2011-02-14T17:12:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Miles Bader writes:\n\n> Michael J Gruber writes:\n>> Short options should really not be \"wasted\" easily. \"-s\" named after \"to\n>> stage\" is really problematic, as outlined in this thread.\n>\n> Er, but the point is that this is _such_ a common operation, that a\n> short option for it would not be \"wasted\" at all.\n\nTrue, but I am afraid \"-c\" is not it, as it would certainly be confusing\nto users who know what \"diff\" does before they learn \"git diff\".\n\nAnd I'd like to also keep \"-i\" open for \"ignore case\", which I actually\nwished the other day while reviewing a topic. Unlike \"-c\", I might\nimplement it myself not in a distant future when I find time.\n\nUsing \"-I\" (as an abbreviation for \"index-only\") is tempting, though.\n\nBoth \"-i\" and \"-I\" are GNU extensions, and the latter traditionally was\nuseful primarily to ignore cruft left in the file with use of \"$Id$\", but\nwe actively discourage its use in git controlled projects, so taking it\nover might not be such a big issue.\n"},{"id":"161118","messageId":"AANLkTinnCLVDEZpNPVYZ2fq1BY=257BTxkzNj44-Yz3O@mail.gmail.com","threadId":"26489","inReplyTo":"7vtyg6tu9e.fsf@alter.siamese.dyndns.org","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2011-02-14T22:07:03Z","receivedAt":"2011-02-14T22:07:03Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"On Tue, Feb 15, 2011 at 2:12 AM, Junio C Hamano wrote:\n> Miles Bader writes:\n>> Michael J Gruber writes:\n>>> Short options should really not be \"wasted\" easily. \"-s\" named after \"to\n>>> stage\" is really problematic, as outlined in this thread.\n>>\n>> Er, but the point is that this is _such_ a common operation, that a\n>> short option for it would not be \"wasted\" at all.\n>\n> True, but I am afraid \"-c\" is not it, as it would certainly be confusing\n> to users who know what \"diff\" does before they learn \"git diff\".\n\nEr...?\n\nHere we were talking about using \"-s\" (inspired by \"--staged\"), which\nI suggested because you earlier objected to \"-c\"...\n\n-miles\n\n-- \nCat is power.  Cat is peace.\n"},{"id":"161122","messageId":"AANLkTim4UKxYwRagCk3R20e7wsRb7CxvS_ze9b8MfWjL@mail.gmail.com","threadId":"26489","inReplyTo":"7v8vxjwnhj.fsf@alter.siamese.dyndns.org","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki.news@gmail.com","sentAt":"2011-02-14T22:32:39Z","receivedAt":"2011-02-14T22:32:39Z","isPatch":false,"sender":{"key":"piotr.krukowiecki.news@gmail.com","avatar":null},"body":"On Sun, Feb 13, 2011 at 11:58 PM, Junio C Hamano wrote:\n> Jonathan Nieder writes:\n[...]\n\nThanks for the explanation.\n\nMy point is:\n1. using multiple terms is confusing\n2. using not descriptive terms is confusing (or at least increases learning\n curve)\n\nIdeally only one should be used - the rest should be obsoleted/hidden from\nend user.\n\nExample from git-status:\n\n - 'git status' outputs <...\" to unstage>>\n But in the man page there is nothing about staging!\n\n - the output does not mention \"index\" at all - only files tracked,\n untracked, to be committed\n\n - man page talks about index or index file exclusively, e.g.:\n \"differences between the index file and the current HEAD commit\",\n \"updated in index\", \"added to index\"\n\n\nIn other places \"index\" is called \"staging area\" and act of updating the index\nis called \"staging in the index\".\n\nI ask: why do we need the \"index\" term at all?\n\n - instead of \"index\" use \"staging\" and \"staging area\"\n - instead of \"listed in index\" use \"staged\" or \"tracked\"\n\nWhat is used internally is one thing, but what the end user (not git developer)\nsees does not have to be related.\n\n(I'm not sure about the \"tracked vs staged\" - maybe we should again get rid of\none of them, at least in some cases.)\n\nIn fact it's not that important how it is called, as long as it meets the\npoints from the beginning of the mail.\n\n\nAs you can see I'm advocating for the use of the \"staging\" term after all.\nI'm new to git and a non-native English speaker. \"Staging\" seems most clear of\nall of the terms. You may find it differently, but please take into\nconsideration that you are accustomed to it.\n\n\"Staging\" gives me the feeling of changing states - from working tree to\nreal commit - which I believe is the purpose of it.\n\n\n\"Caching\" means something used e.g. to improve performance. You can read the\ncache, update it using original item - but the cache is just a function of the\noriginal content.\n\nProbably most common place when users meet \"cache\" is browser cache. You\nclear the cache, you set the limit of cache size, but you don't expect it to\nbe important. Definitely unlike \"cache\" in git.\n\n\nI didn't like the \"index\" at all. At first I could not understand why did you\nhave chosen such name. Additionally in many places it's called \"index file\".\nIt increased the confusion - why would I care if it's a file or not?\n\nNow I see you can understand it as indexing files that should be managed by git,\nor indexing changes to be introduced. But I still like \"staging\" better.\n\n\nI've updated docs for several basic commands to see how would it feel to have\n\"staging\" area instead of \"index file\" - and it's not bad IMO. It was basically\nautomatic search&replace, so the result can be improved.\n\n\n\n-- 8< --\nFrom: Piotr Krukowiecki \nDate: Mon, 14 Feb 2011 23:20:07 +0100\nSubject: [PATCH] Changed index term to staging area\n\n---\n Documentation/git-add.txt | 66 +++++++++++++++++++++---------------------\n Documentation/git-apply.txt | 40 ++++++++++++------------\n Documentation/git-commit.txt | 14 ++++----\n Documentation/git-diff.txt | 22 +++++++-------\n Documentation/git-status.txt | 22 +++++++-------\n 5 files changed, 82 insertions(+), 82 deletions(-)\n\ndiff --git a/Documentation/git-add.txt b/Documentation/git-add.txt\nindex a03448f..54a50b7 100644\n--- a/Documentation/git-add.txt\n+++ b/Documentation/git-add.txt\n@@ -3,7 +3,7 @@ git-add(1)\n\n NAME\n ----\n-git-add - Add file contents to the index\n+git-add - Add file contents to the staging area\n\n SYNOPSIS\n --------\n@@ -15,23 +15,23 @@ SYNOPSIS\n\n DESCRIPTION\n -----------\n-This command updates the index using the current content found in\n+This command updates the staging area using the current content found in\n the working tree, to prepare the content staged for the next commit.\n It typically adds the current content of existing paths as a whole,\n but with some options it can also be used to add content with\n only part of the changes made to the working tree files applied, or\n remove paths that do not exist in the working tree anymore.\n\n-The \"index\" holds a snapshot of the content of the working tree, and it\n+The \"staging area\" holds a snapshot of the content of the working tree, and it\n is this snapshot that is taken as the contents of the next commit. Thus\n after making any changes to the working directory, and before running\n the commit command, you must use the `add` command to add any new or\n-modified files to the index.\n+modified files to the staging area.\n\n This command can be performed multiple times before a commit. It only\n adds the content of the specified file(s) at the time the add command is\n run; if you want subsequent changes included in the next commit, then\n-you must run `git add` again to add the new content to the index.\n+you must run `git add` again to add the new content to the staging area.\n\n The `git status` command can be used to obtain a summary of which\n files have changes that are staged for the next commit.\n@@ -72,39 +72,39 @@ OPTIONS\n -i::\n --interactive::\n \tAdd modified contents in the working tree interactively to\n-\tthe index. Optional path arguments may be supplied to limit\n+\tthe staging area. Optional path arguments may be supplied to limit\n \toperation to a subset of the working tree. See ``Interactive\n \tmode'' for details.\n\n -p::\n --patch::\n-\tInteractively choose hunks of patch between the index and the\n-\twork tree and add them to the index. This gives the user a chance\n+\tInteractively choose hunks of patch between the staging area and the\n+\twork tree and add them to the staging area. This gives the user a chance\n \tto review the difference before adding modified contents to the\n-\tindex.\n+\tstaging area.\n +\n This effectively runs `add --interactive`, but bypasses the\n initial command menu and directly jumps to the `patch` subcommand.\n See ``Interactive mode'' for details.\n\n -e, \\--edit::\n-\tOpen the diff vs. the index in an editor and let the user\n+\tOpen the diff vs. the staging area in an editor and let the user\n \tedit it. After the editor was closed, adjust the hunk headers\n-\tand apply the patch to the index.\n+\tand apply the patch to the staging area.\n +\n The intent of this option is to pick and choose lines of the patch to\n apply, or even to modify the contents of lines to be staged. This can be\n quicker and more flexible than using the interactive hunk selector.\n However, it is easy to confuse oneself and create a patch that does not\n-apply to the index. See EDITING PATCHES below.\n+apply to the staging area. See EDITING PATCHES below.\n\n -u::\n --update::\n \tOnly match against already tracked files in\n-\tthe index rather than the working tree. That means that it\n+\tthe staging area rather than the working tree. That means that it\n \twill never stage new files, but that it will stage modified\n \tnew contents of tracked files and that it will remove files\n-\tfrom the index if the corresponding files in the working tree\n+\tfrom the staging area if the corresponding files in the working tree\n \thave been removed.\n +\n If no is given, default to \".\"; in other words,\n@@ -114,21 +114,21 @@ subdirectories.\n -A::\n --all::\n \tLike `-u`, but match against files in the\n-\tworking tree in addition to the index. That means that it\n+\tworking tree in addition to the staging area. That means that it\n \twill find new files as well as staging modified content and\n \tremoving files that are no longer in the working tree.\n\n -N::\n --intent-to-add::\n \tRecord only the fact that the path will be added later. An entry\n-\tfor the path is placed in the index with no content. This is\n+\tfor the path is placed in the staging area with no content. This is\n \tuseful for, among other things, showing the unstaged content of\n \tsuch files with `git diff` and committing them with `git commit\n \t-a`.\n\n --refresh::\n \tDon't add the file(s), but only refresh their stat()\n-\tinformation in the index.\n+\tinformation in the staging area.\n\n --ignore-errors::\n \tIf some files could not be added because of errors indexing\n@@ -205,8 +205,8 @@ The main command loop has 6 subcommands (plus help\nand quit).\n\n status::\n\n- This shows the change between HEAD and index (i.e. what will be\n- committed if you say `git commit`), and between index and\n+ This shows the change between HEAD and staging area (i.e. what will be\n+ committed if you say `git commit`), and between staging area and\n working tree files (i.e. what you could stage further before\n `git commit` using `git add`) for each path. A sample output\n looks like this:\n@@ -219,11 +219,11 @@ status::\n +\n It shows that foo.png has differences from HEAD (but that is\n binary so line count cannot be shown) and there is no\n-difference between indexed copy and the working tree\n+difference between staged copy and the working tree\n version (if the working tree version were also different,\n 'binary' would have been shown in place of 'nothing'). The\n other file, git-add{litdd}interactive.perl, has 403 lines added\n-and 35 lines deleted if you commit what is in the index, but\n+and 35 lines deleted if you commit what is in the staging area, but\n working tree file has further modifications (one addition and\n one deletion).\n\n@@ -254,7 +254,7 @@ Update>> -2\n ------------\n +\n After making the selection, answer with an empty line to stage the\n-contents of working tree files for selected paths in the index.\n+contents of working tree files for selected paths in the staging area.\n\n revert::\n\n@@ -265,12 +265,12 @@ revert::\n add untracked::\n\n This has a very similar UI to 'update' and\n- 'revert', and lets you add untracked paths to the index.\n+ 'revert', and lets you add untracked paths to the staging area.\n\n patch::\n\n This lets you choose one path out of a 'status' like selection.\n- After choosing the path, it presents the diff between the index\n+ After choosing the path, it presents the diff between the staging area\n and the working tree file and asks you if you want to stage\n the change of each hunk. You can say:\n\n@@ -290,12 +290,12 @@ patch::\n ? - print help\n +\n After deciding the fate for all hunks, if there is any hunk\n-that was chosen, the index is updated with the selected hunks.\n+that was chosen, the staging area is updated with the selected hunks.\n\n diff::\n\n This lets you review what will be committed (i.e. between\n- HEAD and index).\n+ HEAD and staging area).\n\n\n EDITING PATCHES\n@@ -303,10 +303,10 @@ EDITING PATCHES\n\n Invoking `git add -e` or selecting `e` from the interactive hunk\n selector will open a patch in your editor; after the editor exits, the\n-result is applied to the index. You are free to make arbitrary changes\n+result is applied to the staging area. You are free to make arbitrary changes\n to the patch, but note that some changes may have confusing results, or\n even result in a patch that cannot be applied. If you want to abort the\n-operation entirely (i.e., stage nothing new in the index), simply delete\n+operation entirely (i.e., stage nothing new in the staging area), simply delete\n all lines of the patch. The list below describes some common things you\n may see in a patch, and which editing operations make sense on them.\n\n@@ -327,13 +327,13 @@ Modified content is represented by \"-\" lines\n(removing the old content)\n followed by \"{plus}\" lines (adding the replacement content). You can\n prevent staging the modification by converting \"-\" lines to \" \", and\n removing \"{plus}\" lines. Beware that modifying only half of the pair is\n-likely to introduce confusing changes to the index.\n+likely to introduce confusing changes to the staging area.\n --\n\n There are also more complex operations that can be performed. But beware\n-that because the patch is applied only to the index and not the working\n-tree, the working tree will appear to \"undo\" the change in the index.\n-For example, introducing a new line into the index that is in neither\n+that because the patch is applied only to the staging area and not the working\n+tree, the working tree will appear to \"undo\" the change in the staging area.\n+For example, introducing a new line into the staging area that is in neither\n the HEAD nor the working tree will stage the new line for commit, but\n the line will appear to be reverted in the working tree.\n\n@@ -342,7 +342,7 @@ Avoid using these constructs, or do so with extreme caution.\n --\n removing untouched content::\n\n-Content which does not differ between the index and working tree may be\n+Content which does not differ between the staging area and working tree may be\n shown on context lines, beginning with a \" \" (space). You can stage\n context lines for removal by converting the space to a \"-\". The\n resulting working tree file will appear to re-add the content.\ndiff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt\nindex 881652f..9b5a037 100644\n--- a/Documentation/git-apply.txt\n+++ b/Documentation/git-apply.txt\n@@ -3,16 +3,16 @@ git-apply(1)\n\n NAME\n ----\n-git-apply - Apply a patch to files and/or to the index\n+git-apply - Apply a patch to files and/or to the staging area\n\n\n SYNOPSIS\n --------\n [verse]\n-'git apply' [--stat] [--numstat] [--summary] [--check] [--index]\n+'git apply' [--stat] [--numstat] [--summary] [--check] [--staged]\n \t [--apply] [--no-add] [--build-fake-ancestor=] [-R | --reverse]\n \t [--allow-binary-replacement | --binary] [--reject] [-z]\n-\t [-p] [-C] [--inaccurate-eof] [--recount] [--cached]\n+\t [-p] [-C] [--inaccurate-eof] [--recount] [--staged-only]\n \t [--ignore-space-change | --ignore-whitespace ]\n \t [--whitespace=(nowarn|warn|fix|error|error-all)]\n \t [--exclude=] [--include=] [--directory=]\n@@ -21,8 +21,8 @@ SYNOPSIS\n DESCRIPTION\n -----------\n Reads the supplied diff output (i.e. \"a patch\") and applies it to files.\n-With the `--index` option the patch is also applied to the index, and\n-with the `--cache` option the patch is only applied to the index.\n+With the `--staged` option the patch is also applied to the staging area, and\n+with the `--staged-only` option the patch is only applied to the staging area.\n Without these options, the command applies the patch only to files,\n and does not require them to be in a git repository.\n\n@@ -55,32 +55,32 @@ OPTIONS\n\n --check::\n \tInstead of applying the patch, see if the patch is\n-\tapplicable to the current working tree and/or the index\n-\tfile and detects errors. Turns off \"apply\".\n+\tapplicable to the current working tree and/or the staging\n+\tarea and detects errors. Turns off \"apply\".\n\n---index::\n+--staged::\n \tWhen `--check` is in effect, or when applying the patch\n \t(which is the default when none of the options that\n \tdisables it is in effect), make sure the patch is\n-\tapplicable to what the current index file records. If\n+\tapplicable to what the current staging area records. If\n \tthe file to be patched in the working tree is not\n \tup-to-date, it is flagged as an error. This flag also\n-\tcauses the index file to be updated.\n+\tcauses the staging area to be updated.\n\n---cached::\n+--staged-only::\n \tApply a patch without touching the working tree. Instead take the\n-\tcached data, apply the patch, and store the result in the index\n-\twithout using the working tree. This implies `--index`.\n+\tsttaged data, apply the patch, and store the result in the staging area\n+\twithout using the working tree. This implies `--staged`.\n\n --build-fake-ancestor=::\n-\tNewer 'git diff' output has embedded 'index information'\n+\tNewer 'git diff' output has embedded 'staging area information'\n \tfor each blob to help identify the original version that\n \tthe patch applies to. When this flag is given, and if\n \tthe original versions of the blobs are available locally,\n-\tbuilds a temporary index containing those blobs.\n+\tbuilds a temporary staging area containing those blobs.\n +\n-When a pure mode change is encountered (which has no index information),\n-the information is read from the current index instead.\n+When a pure mode change is encountered (which has no staging area information),\n+the information is read from the current staging area instead.\n\n -R::\n --reverse::\n@@ -236,13 +236,13 @@ Submodules\n If the patch contains any changes to submodules then 'git apply'\n treats these changes as follows.\n\n-If `--index` is specified (explicitly or implicitly), then the submodule\n-commits must match the index exactly for the patch to apply. If any\n+If `--staged` is specified (explicitly or implicitly), then the submodule\n+commits must match the staging area exactly for the patch to apply. If any\n of the submodules are checked-out, then these check-outs are completely\n ignored, i.e., they are not required to be up-to-date or clean and they\n are not updated.\n\n-If `--index` is not specified, then the submodule commits in the patch\n+If `--staged` is not specified, then the submodule commits in the patch\n are ignored and only the absence or presence of the corresponding\n subdirectory is checked and (if possible) updated.\n\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex b586c0f..728b2cf 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -16,26 +16,26 @@ SYNOPSIS\n\n DESCRIPTION\n -----------\n-Stores the current contents of the index in a new commit along\n+Stores the current contents of the staging area in a new commit along\n with a log message from the user describing the changes.\n\n The content to be added can be specified in several ways:\n\n 1. by using 'git add' to incrementally \"add\" changes to the\n- index before using the 'commit' command (Note: even modified\n+ staging area before using the 'commit' command (Note: even modified\n files must be \"added\");\n\n 2. by using 'git rm' to remove files from the working tree\n- and the index, again before using the 'commit' command;\n+ and the staging area, again before using the 'commit' command;\n\n 3. by listing files as arguments to the 'commit' command, in which\n- case the commit will ignore changes staged in the index, and instead\n+ case the commit will ignore changes staged in the staging area, and instead\n record the current content of the listed files (which must already\n be known to git);\n\n 4. by using the -a switch with the 'commit' command to automatically\n \"add\" changes from all known files (i.e. all files that are already\n- listed in the index) and to automatically \"rm\" files in the index\n+ tracked) and to automatically \"rm\" tracked files\n that have been removed from the working tree, and then perform the\n actual commit;\n\n@@ -273,8 +273,8 @@ EXAMPLES\n --------\n When recording your own work, the contents of modified files in\n your working tree are temporarily stored to a staging area\n-called the \"index\" with 'git add'. A file can be\n-reverted back, only in the index but not in the working tree,\n+ with 'git add'. A file can be\n+reverted back, only in the staging area but not in the working tree,\n to that of the last commit with `git reset HEAD -- `,\n which effectively reverts 'git add' and prevents the changes to\n this file from participating in the next commit. After building\ndiff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt\nindex 4910510..eab118a 100644\n--- a/Documentation/git-diff.txt\n+++ b/Documentation/git-diff.txt\n@@ -10,29 +10,29 @@ SYNOPSIS\n --------\n [verse]\n 'git diff' [options] [] [--] [...]\n-'git diff' [options] --cached [] [--] [...]\n+'git diff' [options] --staged [] [--] [...]\n 'git diff' [options] [--] [...]\n-'git diff' [options] [--no-index] [--] \n+'git diff' [options] [--not-staged] [--] \n\n DESCRIPTION\n -----------\n-Show changes between the working tree and the index or a tree, changes\n-between the index and a tree, changes between two trees, or changes\n+Show changes between the working tree and the staging area or a tree, changes\n+between the staging area and a tree, changes between two trees, or changes\n between two files on disk.\n\n 'git diff' [--options] [--] [...]::\n\n \tThis form is to view the changes you made relative to\n-\tthe index (staging area for the next commit). In other\n+\tthe staging area for the next commit. In other\n \twords, the differences are what you _could_ tell git to\n-\tfurther add to the index but you still haven't. You can\n+\tfurther add to the staging area but you still haven't. You can\n \tstage these changes by using linkgit:git-add[1].\n +\n If exactly two paths are given and at least one points outside\n the current repository, 'git diff' will compare the two files /\n-directories. This behavior can be forced by --no-index.\n+directories. This behavior can be forced by --not-staged.\n\n-'git diff' [--options] --cached [] [--] [...]::\n+'git diff' [--options] --staged [] [--] [...]::\n\n \tThis form is to view the changes you staged for the next\n \tcommit relative to the named . Typically you\n@@ -40,7 +40,7 @@ directories. This behavior can be forced by --no-index.\n \tdo not give , it defaults to HEAD.\n \tIf HEAD does not exist (e.g. unborned branches) and\n \t is not given, it shows all staged changes.\n-\t--staged is a synonym of --cached.\n+\t--cached is a synonym of --staged, will be removed in version 2.0\n(or whatever).\n\n 'git diff' [--options] [--] [...]::\n\n@@ -102,12 +102,12 @@ Various ways to check your working tree::\n +\n ------------\n $ git diff <1>\n-$ git diff --cached <2>\n+$ git diff --staged <2>\n $ git diff HEAD <3>\n ------------\n +\n <1> Changes in the working tree not yet staged for the next commit.\n-<2> Changes between the index and your last commit; what you\n+<2> Changes between the staging area and your last commit; what you\n would be committing if you run \"git commit\" without \"-a\" option.\n <3> Changes in the working tree since your last commit; what you\n would be committing if you run \"git commit -a\"\ndiff --git a/Documentation/git-status.txt b/Documentation/git-status.txt\nindex dae190a..65aa798 100644\n--- a/Documentation/git-status.txt\n+++ b/Documentation/git-status.txt\n@@ -12,9 +12,9 @@ SYNOPSIS\n\n DESCRIPTION\n -----------\n-Displays paths that have differences between the index file and the\n+Displays paths that have differences between the staging area and the\n current HEAD commit, paths that have differences between the working\n-tree and the index file, and paths in the working tree that are not\n+tree and the staging area, and paths in the working tree that are not\n tracked by git (and are not ignored by linkgit:gitignore[5]). The first\n are what you _would_ commit by running `git commit`; the second and\n third are what you _could_ commit by running 'git add' before running\n@@ -91,7 +91,7 @@ In short-format, the status of each path is shown as\n\n where `PATH1` is the path in the `HEAD`, and ` -> PATH2` part is\n shown only when `PATH1` corresponds to a different path in the\n-index/worktree (i.e. the file is renamed). The 'XY' is a two-letter\n+staging area/worktree (i.e. the file is renamed). The 'XY' is a two-letter\n status code.\n\n The fields (including the `->`) are separated from each other by a\n@@ -102,7 +102,7 @@ interior special characters backslash-escaped.\n\n For paths with merge conflicts, `X` and 'Y' show the modification\n states of each side of the merge. For paths that do not have merge\n-conflicts, `X` shows the status of the index, and `Y` shows the status\n+conflicts, `X` shows the status of the staging area, and `Y` shows the status\n of the work tree. For untracked paths, `XY` are `??`. Other status\n codes can be interpreted as follows:\n\n@@ -119,13 +119,13 @@ Ignored files are not listed.\n X Y Meaning\n -------------------------------------------------\n [MD] not updated\n- M [ MD] updated in index\n- A [ MD] added to index\n- D [ M] deleted from index\n- R [ MD] renamed in index\n- C [ MD] copied in index\n- [MARC] index and work tree matches\n- [ MARC] M work tree changed since index\n+ M [ MD] updated in staging area\n+ A [ MD] added to staging area\n+ D [ M] deleted from staging area\n+ R [ MD] renamed in staging area\n+ C [ MD] copied in staging area\n+ [MARC] staging area and work tree matches\n+ [ MARC] M work tree changed since staging area\n [ MARC] D deleted in work tree\n -------------------------------------------------\n D D unmerged, both deleted\n-- \n1.7.4.1.26.g00e6e\n"},{"id":"161126","messageId":"7vzkpyql2r.fsf@alter.siamese.dyndns.org","threadId":"26489","inReplyTo":"AANLkTinnCLVDEZpNPVYZ2fq1BY=257BTxkzNj44-Yz3O@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-14T22:59:24Z","receivedAt":"2011-02-14T22:59:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Miles Bader writes:\n\n> Er...?\n>\n> Here we were talking about using \"-s\" (inspired by \"--staged\"), which\n> I suggested because you earlier objected to \"-c\"...\n\nNot _we were_, but _you_ were.\n\nI actually was hoping that it was obvious that -s is a no-starter from the\nmessages so far in this thread, as neither --cached nor its more\ndescriptive spelling --index-only has character 's' anywhere in it, and we\nhave been keeping --staged as a low-key synonym for a reason.\n"},{"id":"161129","messageId":"20110214231920.GA24814@elie","threadId":"26489","inReplyTo":"AANLkTim4UKxYwRagCk3R20e7wsRb7CxvS_ze9b8MfWjL@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-14T23:19:20Z","receivedAt":"2011-02-14T23:19:20Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi again,\n\nPiotr Krukowiecki wrote:\n\n> In other places \"index\" is called \"staging area\" and act of updating the index\n> is called \"staging in the index\".\n>\n> I ask: why do we need the \"index\" term at all?\n>\n> - instead of \"index\" use \"staging\" and \"staging area\"\n> - instead of \"listed in index\" use \"staged\" or \"tracked\"\n\nUnlike \"staging area\", the word \"index\" is unfamiliar and opaque. So\nthere is a sense that there is something to learn.\n\nWhen people talk about the staging area I tend to get confused. I\nthink there's an idea that because it sounds more concrete, there is\nless to explain --- or maybe I am just wired the wrong way.\n\nThere is a .git/index file, with a well defined file format. And\nthere is an in-core copy of the index, too. It contains:\n\n - mode and blob name for paths as requested by the user with\n \"git add\"\n\n - competing versions for paths whose proposed content is\n uncertain during a merge\n\n - stat(2) information to speed up comparison with the worktree\n\nThere are some other pieces, too --- \"intent-to-add\" entries added\nwith \"git add -N\", cached tree names for unmodified subtrees to\nspeed up \"git commit\", and so on. But the 3 pieces listed above are\nthe main thing.\n\n\"Staging area\" only describes the first.\n\nAll that said, I am not against formulations like \"content of the next\ncommit\" that might be more concrete from a user's point of view.\n\n[...]\n> --refresh::\n> \tDon't add the file(s), but only refresh their stat()\n> -\tinformation in the index.\n> +\tinformation in the staging area.\n\ngit add/update-index --refresh are precisely meant for _not_ changing\nthe content of the next commit, so this particular change seems\nconfusing.\n\nHoping that is clearer. Thanks for caring.\nJonathan\n"},{"id":"161134","messageId":"AANLkTikyc5QEou8Em-3HkLSHWHQyx+MnYMQ9OSN33_QS@mail.gmail.com","threadId":"26489","inReplyTo":"7vzkpyql2r.fsf@alter.siamese.dyndns.org","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2011-02-14T23:47:00Z","receivedAt":"2011-02-14T23:47:00Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"On Tue, Feb 15, 2011 at 7:59 AM, Junio C Hamano wrote:\n> I actually was hoping that it was obvious that -s is a no-starter from the\n> messages so far in this thread, as neither --cached nor its more\n> descriptive spelling --index-only has character 's' anywhere in it, and we\n> have been keeping --staged as a low-key synonym for a reason.\n\nIt was not at all obvious. Even if you like --cached more than\n--staged, there's a difference between advocating \"--staged\", and\nusing \"-s\" as a short-option for the operation which --cached /\n--staged invoke.\n\nShort option names are often a compromise, because clearly there are\noften conflicts. That _doesn't_ mean that one should simply not have\na short option, when a \"perfect\" choice cannot be found. If a\n\"perfect\" short-option isn't available, then usually one turns to\nsomewhat less perfect choices, trying to at least find some heuristic\nthat can make them easier to memorize -- because in the end, short\noptions must be memorized (and if they are truly common operations,\nthis isn't generally difficult; it's memorizing _rarely_ used short\noptions that's hard).\n\nOf the various choices, \"-s\" does at least have such a heuristic\nconnection to an appropriate long option (\"-i\" is arguably worse than\n-s, because it doesn't have any such connection...). Can you suggest\nsomething better?\n\n[BTW, isn't the name \"--index-only\" something of a misnomer? If\nsomething is called \"--XXX-only\", that implies that the default\noperation uses \"XXX + something else\" instead of XXX, but that\notherwise they are the same. However in fact the difference in\nbehavior resulting from --cached is more subtle: it changes _both_\nsides of the diff (default: worktree<->index; --cached: index<->HEAD).\n The names --cached and --staged actually capture this well -- they\nbasically say \"the default is worktree changes, and --cached/--staged\ndiffs cached/staged changes instead\" -- but the name \"--index-only\"\ndoes not.]\n\n-Miles\n\n-- \nCat is power.  Cat is peace.\n"},{"id":"161135","messageId":"7vaahyqhor.fsf@alter.siamese.dyndns.org","threadId":"26489","inReplyTo":"AANLkTikyc5QEou8Em-3HkLSHWHQyx+MnYMQ9OSN33_QS@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-15T00:12:36Z","receivedAt":"2011-02-15T00:12:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Miles Bader writes:\n\n> [BTW, isn't the name \"--index-only\" something of a misnomer? If\n> something is called \"--XXX-only\", that implies that the default\n> operation uses \"XXX + something else\" instead of XXX, but that\n> otherwise they are the same. However in fact the difference in\n> behavior resulting from --cached is more subtle: it changes _both_\n> sides of the diff (default: worktree<->index; --cached: index<->HEAD).\n\nNot really.\n\nThere are three entities involved: a tree-ish, the index, and the working\ntree. Because the index is a singleton, when you say \"compare the index\nwith...\", you only have two choices, either compare it against a tree-ish,\nor compare it with the working tree. If you want to do the latter, you\njust use the command without --cached nor tree-ish.\n\nThe --cached form defaults to HEAD only because --cached mode is about\ncomparing the index against a tree-ish (think about \"diff --cached HEAD^\").\n\nThe same thing for --index-only. The moment you said \"compare the index\nwith...\", there are only two other things to compare it against and that\nis the only reason why you do not have to write HEAD.\n\nThis is a tangent, but the natural patch-flow is for you to prepare your\nchange in the working tree, add the changes to the index, and then build a\ntree out of the index into a commit.\n\nThat is why \"diff\" shows changes in the working tree relative to what is\nin the index, \"diff --cached []\" shows changes in the index\nrelative to the tree-ish (defaulting to HEAD). The natural flow of the\ndevelopment determines the natural direction of comparison between these\nentities.\n\nIt does not make sense to compare in the other direction (i.e. how is the\nindex different compared to the working tree) _unless_ you are\ncontemplating to revert some changes you have made, and -R is there\nexactly for that reason (here I am responding to the idea some people had\nin an earlier incarnation of this thread of saying \"diff INDEX HEAD\",\n\"diff HEAD WORKTREE\" etc., using pseudo syntax, and explaining why\nit is not such a good idea---and why this is a tangent).\n"},{"id":"161160","messageId":"4D5A3964.9090209@pcharlan.com","threadId":"26489","inReplyTo":"20110214231920.GA24814@elie","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Pete Harlan","fromEmail":"pgit@pcharlan.com","sentAt":"2011-02-15T08:29:24Z","receivedAt":"2011-02-15T08:29:24Z","isPatch":false,"sender":{"key":"pgit@pcharlan.com","avatar":null},"body":"On 02/14/2011 03:19 PM, Jonathan Nieder wrote:\n> Hi again,\n> \n> Piotr Krukowiecki wrote:\n> \n>> In other places \"index\" is called \"staging area\" and act of updating the index\n>> is called \"staging in the index\".\n>>\n>> I ask: why do we need the \"index\" term at all?\n>>\n>> - instead of \"index\" use \"staging\" and \"staging area\"\n>> - instead of \"listed in index\" use \"staged\" or \"tracked\"\n> \n> Unlike \"staging area\", the word \"index\" is unfamiliar and opaque. So\n> there is a sense that there is something to learn.\n>\n> When people talk about the staging area I tend to get confused. I\n> think there's an idea that because it sounds more concrete, there is\n> less to explain --- or maybe I am just wired the wrong way.\n> \n> There is a .git/index file, with a well defined file format. And\n> there is an in-core copy of the index, too. It contains:\n> \n> - mode and blob name for paths as requested by the user with\n> \"git add\"\n> \n> - competing versions for paths whose proposed content is\n> uncertain during a merge\n> \n> - stat(2) information to speed up comparison with the worktree\n> \n> There are some other pieces, too --- \"intent-to-add\" entries added\n> with \"git add -N\", cached tree names for unmodified subtrees to\n> speed up \"git commit\", and so on. But the 3 pieces listed above are\n> the main thing.\n\nThank you for that explanation.\n\n> \"Staging area\" only describes the first.\n\n...which to me means only that \"staging area\" isn't enough to fully\ndescribe what Git can do.\n\n>From the user's perspective, merge conflict resolution is a separate\nprocess from staging a commit; where does Git's usability benefit from\nblending the two concepts by referring (in command syntax and\nmanpages) to their common internal data structure?\n\nOne of Git's charms is the simplicity of blobs, trees, commits and\ntags and how those ingredients prove tremendously useful in developing\nsoftware. And I don't think anyone can use Git well without fully\nunderstanding what those structures are (and are not).\n\nBut I believe the rest of Git's internals are in a different category.\nRegardless of how elegant the solution may be, as a user I can use Git\nwell without knowing _how_ Git can tell that foo.c contains staged and\nunstaged changes. Nor do I need to know how it knows that bar.c is in\nconflict. I don't need to know precisely how it implements its packed\nobject database to use it effectively.\n\nPart of the issue could be that one intimately familiar with Git's\ninternals may find a process oriented interface irritating (\"Why must\nit say 'staging area' when it's just updating the index?\"), while one\nunfamiliar with the internals has the opposite reaction (\"Why must it\nmake me use the internal name of the staging area?\").\n\nSomeone suggested using a different top-level name for Git to allow\nfor completely rewriting the interface. I expect that it's this\ndifference of perspective that makes that appear necessary. I believe\nthat a rewrite is the wrong approach, but I believe that abstractions\nlike \"staging area\" move the user-interface a little more toward the\nuser and that there's value in that.\n\n--Pete\n\n> All that said, I am not against formulations like \"content of the next\n> commit\" that might be more concrete from a user's point of view.\n> \n> [...]\n>> --refresh::\n>> \tDon't add the file(s), but only refresh their stat()\n>> -\tinformation in the index.\n>> +\tinformation in the staging area.\n> \n> git add/update-index --refresh are precisely meant for _not_ changing\n> the content of the next commit, so this particular change seems\n> confusing.\n> \n> Hoping that is clearer. Thanks for caring.\n> Jonathan\n"},{"id":"161164","messageId":"20110215090009.GA22498@elie","threadId":"26489","inReplyTo":"4D5A3964.9090209@pcharlan.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-15T09:00:09Z","receivedAt":"2011-02-15T09:00:09Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Pete,\n\nPete Harlan wrote:\n\n> Part of the issue could be that one intimately familiar with Git's\n> internals may find a process oriented interface irritating (\"Why must\n> it say 'staging area' when it's just updating the index?\")\n\nNo, no. I agree there's a problem to solve here. The current\ndocumentation for git (e.g., the user manual) has a nice, coherent,\nuser-oriented narrative about trees, commits, and blobs, and meanwhile\nit is hard to find a clear story about the index.\n\nSuch a story would have to describe the conflict resolution process.\nWhen you encounter a merge conflict, how do you resolve it? The best\nI can do for now is to point to the user manual[1].\n\nhttp://www.kernel.org/pub/software/scm/git/docs/user-manual.html#conflict-resolution\n\nI even think it is okay to say \"The index is a sort of staging area\nfor your next commit\". Because that is true. But it is not the full\nstory, so if one wants to give the index a new name --- which is a\ncostly thing to do, anyway --- then I do not think \"the staging area\"\nworks.\n\nI feel bad to only be presenting complications instead of an alternate\nsolution. I do consider workflow oriented explanations very useful.\nI've been giving technical explanations in this thread as background\nfor future storytelling, in the hope that someone more talented than I\nam can digest it into a good narrative.\n\nJonathan\n\n[1] Maybe the process is overdesigned. After all, what would we lose\nby saying\n\n - an unmerged path justs gets an \"unmerged\" flag set, meaning that\n flag is not ready for commit yet\n - to get the copy from the common ancestor, use\n\tgit show $(git merge-base HEAD MERGE_HEAD):path/to/file\n - to get the copy from HEAD, use\n\tgit show HEAD:path/to/file\n - likewise to get the copy from MERGE_HEAD\n\nAnd while I can give answers about why that is a bad interface\n(recomputing the merge base is a waste of time; in a recursive merge\nthe merge base is not a real commit; if there were renames, the copy\nfrom HEAD could be HEAD:other/path and it is hard to find what\nother/path is), are those answers enough to justify learning this new\ntrick?\n\nSo we need a better story.\n"},{"id":"161199","messageId":"AANLkTim3g15GRZUhrq4=Bs28JHr3M53U_QavtyUxsh7L@mail.gmail.com","threadId":"26489","inReplyTo":"20110214231920.GA24814@elie","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki@gmail.com","sentAt":"2011-02-15T18:15:31Z","receivedAt":"2011-02-15T18:15:31Z","isPatch":false,"sender":{"key":"piotr.krukowiecki@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3259959?v=4"},"body":"On Tue, Feb 15, 2011 at 12:19 AM, Jonathan Nieder wrote:\n> Hi again,\n>\n> Piotr Krukowiecki wrote:\n>>  --refresh::\n>>       Don't add the file(s), but only refresh their stat()\n>> -     information in the index.\n>> +     information in the staging area.\n>\n> git add/update-index --refresh are precisely meant for _not_ changing\n> the content of the next commit, so this particular change seems\n> confusing.\n\nIf there is no staging - no commit, then you're right. But then you don't\nhave to mention index at all:\n\n  --refresh::\n       Don't add the file(s), but only refresh their stat()\n     information.\n\nI completely agree with Pete Harlan - for normal user git internals are\nnot relevant - index is just part of git. How or where the stat information is\nrefreshed does not matter.\n\nIn the same way you don't write that it's done by function refresh_index().\n\n\n> Hoping that is clearer.  Thanks for caring.\n> Jonathan\n\nThanks for explanation.\n\n\n-- \nPiotrek\n"},{"id":"161200","messageId":"20110215183816.GB26405@elie","threadId":"26489","inReplyTo":"AANLkTim3g15GRZUhrq4=Bs28JHr3M53U_QavtyUxsh7L@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-15T18:38:16Z","receivedAt":"2011-02-15T18:38:16Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Piotr Krukowiecki wrote:\n>> Piotr Krukowiecki wrote:\n\n>>>  --refresh::\n>>>       Don't add the file(s), but only refresh their stat()\n>>> -     information in the index.\n>>> +     information in the staging area.\n[...]\n> If there is no staging - no commit, then you're right. But then you don't\n> have to mention index at all:\n>\n>  --refresh::\n>       Don't add the file(s), but only refresh their stat()\n>     information.\n\nYes, that sounds like an improvement. Though I'd suggest something\nlike:\n\n --refresh::\n\tDon't add the files' content and mode, but refresh their stat(2)\n\tinformation if it is out of date. For example, you'd want to\n\tdo this after restoring a repository from backup, to link up\n\tthe stat index details with the proper files.\n\nThe exact wording could use tweaking, but hopefully the idea is clear\n(to explain what the option is actually used for).\n\n> index is just part of git. How or where the stat information is\n> refreshed does not matter.\n\nI agree with that. That this is (1) specific to that index, so the\noperation needs to be repeated if you use GIT_INDEX_FILE to work with\na second index and (2) has as its only purpose speeding up operations\nthat compare the index to the worktree are relevant, though.\n\nAnyway, I don't want to argue. Many of the places pointed out in\nthe manual could use help. It could even involve inserting the\nphrase \"a staging area\".\n\nHopefully I have made clear why excising the word \"index\" from git\nvocabulary (like the word \"current directory cache\" was eventually\neliminated over time in the past) does not seem like a good idea when\nwe don't even have a good alternative for it. As the original post\nmentioned, using three terms in documentation for fundamentally the\nsame thing is going to get confusing after a while. Why not just use\none (\"the index\")?\n\nSorry for the ramble.\nJonathan\n"},{"id":"161356","messageId":"1297897887.24521.57.camel@drew-northup.unet.maine.edu","threadId":"26489","inReplyTo":"4D589CE0.7020203@pcharlan.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2011-02-16T23:11:27Z","receivedAt":"2011-02-16T23:11:27Z","isPatch":false,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Sun, 2011-02-13 at 19:09 -0800, Pete Harlan wrote:\n> On 02/13/2011 02:58 PM, Junio C Hamano wrote:\n> >> --staged\n> >> ~~~~~~~~\n> >> diff takes --staged, but that is only to support some people's habits.\n> > The term \"stage\" comes from \"staging area\", a term people used to explain\n> > the concept of the index by saying \"The index holds set of contents to be\n> > made into the next commit; it is _like_ the staging area\".\n> > \n> > My feeling is that \"to stage\" is primarily used, outside \"git\" circle, as\n> > a logistics term. If you find it easier to visualize the concept of the\n> > index with \"staging area\" (\"an area where troops and equipment in transit\n> > are assembled before a military operation\", you may find it easier to say\n> > \"stage this path ('git add path')\", instead of \"adding to the set of\n> > contents...\".\n> \n> FWIW, when teaching Git I have found that users immediately understand\n> \"staging area\", while \"index\" and \"cache\" confuse them.\n> \n> \"Index\" means to them a numerical index into a data structure.\n> \"Cache\" is a local copy of something that exists remotely. Neither\n> word describes the concept correctly from a user's perspective.\n\nAccording to the dictionary (actually, more than one) \"cache\" is a\nhidden storage space. I'm pretty sure that's the sense most global and\ntherefore most appropriate to thinking about Git. (It certainly\ndescribes correctly what web browser cache and on-CPU cache is doing.)\nOne would only think the definition you gave applied if they didn't know\nthat squirrels \"cache\" nuts. I don't think that the problem is the\nidiom.\n\n> I learned long ago to type \"index\" and \"cached\", but when talking (and\n> thinking) about Git I find \"the staging area\" gets the point across\n> very clearly and moves Git from interesting techie-tool to\n> world-dominating SCM territory. I'm surprised that that experience\n> isn't universal.\n\nPerhaps that helps you associate it with other SCM/VCS software, but it\ndidn't help me. When I realized that the \"index\" is called that BECAUSE\nIT IS AN INDEX (of content/data states for a pending commit operation)\nthe sky cleared and the sun came out.\n\nIn all reality the closest thing Git has to an actual staging area is\nall of the objects in .git/objects only recorded by the index itself.\nGit-stored objects not compressed into pack files could technically be\ndescribed as \"cached\" using the standard definition--they aren't visible\nin the working directory. Unfortunately this probably just muddies the\nwater for all too many users.\n\nSo, in summary--the index is real, objects \"cached\" pending\ncommit/cleanup/packing are real; any \"staging area\" is a rhetorical\ncombination of the two. Given that rhetorical device may not work in all\nlanguages (as Junio mentioned earlier) I don't recommend that we rely on\nit.\n\n-- \n-Drew Northup\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"162323","messageId":"AANLkTincNdUQ=736=M2Oei4LF0pR0c2T7r=bWJE3RFCu@mail.gmail.com","threadId":"26489","inReplyTo":"1297897887.24521.57.camel@drew-northup.unet.maine.edu","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-02-26T20:36:39Z","receivedAt":"2011-02-26T20:36:39Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Feb 17, 2011 at 1:11 AM, Drew Northup wrote:\n>\n> On Sun, 2011-02-13 at 19:09 -0800, Pete Harlan wrote:\n>> On 02/13/2011 02:58 PM, Junio C Hamano wrote:\n>> >> --staged\n>> >> ~~~~~~~~\n>> >> diff takes --staged, but that is only to support some people's habits.\n>> > The term \"stage\" comes from \"staging area\", a term people used to explain\n>> > the concept of the index by saying \"The index holds set of contents to be\n>> > made into the next commit; it is _like_ the staging area\".\n>> >\n>> > My feeling is that \"to stage\" is primarily used, outside \"git\" circle, as\n>> > a logistics term.  If you find it easier to visualize the concept of the\n>> > index with \"staging area\" (\"an area where troops and equipment in transit\n>> > are assembled before a military operation\", you may find it easier to say\n>> > \"stage this path ('git add path')\", instead of \"adding to the set of\n>> > contents...\".\n>>\n>> FWIW, when teaching Git I have found that users immediately understand\n>> \"staging area\", while \"index\" and \"cache\" confuse them.\n>>\n>> \"Index\" means to them a numerical index into a data structure.\n>> \"Cache\" is a local copy of something that exists remotely.  Neither\n>> word describes the concept correctly from a user's perspective.\n>\n> According to the dictionary (actually, more than one) \"cache\" is a\n> hidden storage space. I'm pretty sure that's the sense most global and\n> therefore most appropriate to thinking about Git. (It certainly\n> describes correctly what web browser cache and on-CPU cache is doing.)\n> One would only think the definition you gave applied if they didn't know\n> that squirrels \"cache\" nuts. I don't think that the problem is the\n> idiom.\n\nNot really. If a squirrel \"caches\" nuts, it means a squirrel is\nputting them in a hidden place to save them for future use. So, in the\nfuture, if said squirrel wants a nut, it doesn't have to look for it\nin the trees, just go to the cache. So the cache makes it easier to\naccess whatever your want.\n\nIOW; if you don't cache something, you would have more trouble getting\nit, but you still can.\n\nThat's not what Git is doing. Git is not putting changes in a place so\nthe can be more easily accessed in the future. It is using a temporary\ndevice that allows the commit to be built through an extended period\nof time. It's not a cache.\n\n>> I learned long ago to type \"index\" and \"cached\", but when talking (and\n>> thinking) about Git I find \"the staging area\" gets the point across\n>> very clearly and moves Git from interesting techie-tool to\n>> world-dominating SCM territory.  I'm surprised that that experience\n>> isn't universal.\n>\n> Perhaps that helps you associate it with other SCM/VCS software, but it\n> didn't help me. When I realized that the \"index\" is called that BECAUSE\n> IT IS AN INDEX (of content/data states for a pending commit operation)\n> the sky cleared and the sun came out.\n\nThat's not an index. An index is a guide of pointers to something\nelse. It allows you to find whatever you are looking for by looking in\nsmall table of pointers instead of looking through all the samples.\n\nIOW; if you don't index something, you would have more trouble finding\nit, but you still can.\n\nThat's not what Git is doing.\n\n> In all reality the closest thing Git has to an actual staging area is\n> all of the objects in .git/objects only recorded by the index itself.\n> Git-stored objects not compressed into pack files could technically be\n> described as \"cached\" using the standard definition--they aren't visible\n> in the working directory. Unfortunately this probably just muddies the\n> water for all too many users.\n\nThat's irrelevant. You can implement the same functionality in many\nother ways. How it is implement doesn't matter, what matters is what\nthe user experiences.\n\n> So, in summary--the index is real, objects \"cached\" pending\n> commit/cleanup/packing are real; any \"staging area\" is a rhetorical\n> combination of the two. Given that rhetorical device may not work in all\n> languages (as Junio mentioned earlier) I don't recommend that we rely on\n> it.\n\nBranches and tags are \"rthetorical\" devices as well. But behind scenes\nthey are just refs. Shall we disregard 'branch' and 'tag'?\n\nNo. What Git does behind scenes is irrelevant to the user. What\nmatters is what the device does, not how it is implemented; the\nimplementation might change. \"Stage\" is the perfect word; both verb\nand a noun that express a temporary space where things are prepared\nfor their final form.\n\n-- \nFelipe Contreras\n"},{"id":"162324","messageId":"AANLkTik-jc0ZX9S4bCYV8VBgPXJZsX0U08W2H+jufO8r@mail.gmail.com","threadId":"26489","inReplyTo":"20110214231920.GA24814@elie","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-02-26T21:09:14Z","receivedAt":"2011-02-26T21:09:14Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Feb 15, 2011 at 1:19 AM, Jonathan Nieder wrote:\n> When people talk about the staging area I tend to get confused.  I\n> think there's an idea that because it sounds more concrete, there is\n> less to explain --- or maybe I am just wired the wrong way.\n\nI don't like the phrase \"staging area\". A \"stage\" already has an area.\nYou put things on the stage. Sometimes there are multiple stages.\n\n> There is a .git/index file, with a well defined file format.  And\n> there is an in-core copy of the index, too.  It contains:\n>\n>  - mode and blob name for paths as requested by the user with\n>   \"git add\"\n\nA commit stage.\n\n>  - competing versions for paths whose proposed content is\n>   uncertain during a merge\n\nMultiple commit stages.\n\n>  - stat(2) information to speed up comparison with the worktree\n\nIf only a subset of the files are there, it's an 'index', if not, then\nI'd say it's a 'registry'. Anyway, it's something the user shouldn't\ncare about.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"162325","messageId":"20110226215139.GA19176@elie","threadId":"26489","inReplyTo":"AANLkTik-jc0ZX9S4bCYV8VBgPXJZsX0U08W2H+jufO8r@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-26T21:51:39Z","receivedAt":"2011-02-26T21:51:39Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Felipe et al,\n\nFelipe Contreras wrote:\n> On Tue, Feb 15, 2011 at 1:19 AM, Jonathan Nieder wrote:\n\n>>  - mode and blob name for paths as requested by the user with\n>>   \"git add\"\n>\n> A commit stage.\n>\n>>  - competing versions for paths whose proposed content is\n>>   uncertain during a merge\n>\n> Multiple commit stages.\n>\n>>  - stat(2) information to speed up comparison with the worktree\n>\n> If only a subset of the files are there, it's an 'index', if not, then\n> I'd say it's a 'registry'.\n\nThese terms you suggest aren't the established ones (as I'm sure you\nknow). Just as with everyday language, there is some resistance to\nmoving to new terms that have not been established for a while. In\neveryday language, many terms gained popularity by\n\n - appearing in some document that people read for another reason\n - describing the notion they are meant to describe clearly (or\n having some other feature that makes them likeable)\n\nThis is how \"staging area\" has been gaining popularity, I think ---\nsome (out-of-tree) documentation that is good for other reasons uses\nit, and it really does seem to be a clearer term than \"index\" for\n\"place where the next commit is being prepared\". Unfortunately, I do\nnot think it is a clearer term than \"index\" for \"the git index, which\ncontains stat() information and pointers to blobs that either belong\nin the next commit or are participating in a merge conflict\". So it\ndoes not seem to justify rewriting everything to use it.\n\nWhich suggests one way forward --- if you believe you have terms that\ndo describe those concepts clearly, one way to promote them is to\nwrite some good, clear (out-of-tree, to begin with) documentation\nusing them. Presumably this documentation would also mention that\nother people use other terms to avoid confusing the reader.\n\nHope that helps,\nJonathan\n"},{"id":"162332","messageId":"87wrkmfirm.fsf@catnip.gol.com","threadId":"26489","inReplyTo":"20110226215139.GA19176@elie","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2011-02-27T00:01:01Z","receivedAt":"2011-02-27T00:01:01Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Jonathan Nieder writes:\n> This is how \"staging area\" has been gaining popularity, I think ---\n> some (out-of-tree) documentation that is good for other reasons uses\n> it, and it really does seem to be a clearer term than \"index\" for\n> \"place where the next commit is being prepared\".\n\nAlso \"magit\" uses the label \"Staging area:\" for the list of files to be\ncommitted -- and the key-binding to add a file to that list is \"s\"...\n\n-Miles\n\n-- \nChristian, n. One who follows the teachings of Christ so long as they are not\ninconsistent with a life of sin.\n"},{"id":"162333","messageId":"AANLkTimyXciScc5K6ozggMHsy9YmgyOFpy6pgKBEypC9@mail.gmail.com","threadId":"26489","inReplyTo":"20110226215139.GA19176@elie","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-02-27T00:16:40Z","receivedAt":"2011-02-27T00:16:40Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Feb 26, 2011 at 11:51 PM, Jonathan Nieder wrote:\n> These terms you suggest aren't the established ones (as I'm sure you\n> know).  Just as with everyday language, there is some resistance to\n> moving to new terms that have not been established for a while.  In\n> everyday language, many terms gained popularity by\n>\n>  - appearing in some document that people read for another reason\n>  - describing the notion they are meant to describe clearly (or\n>   having some other feature that makes them likeable)\n\nThere's always resistance, but 1.8 is supposed to contain stuff as \"if\ngit was written from scratch\". I think this makes sense as one of\nthem.\n\n> This is how \"staging area\" has been gaining popularity, I think ---\n> some (out-of-tree) documentation that is good for other reasons uses\n> it, and it really does seem to be a clearer term than \"index\" for\n> \"place where the next commit is being prepared\".  Unfortunately, I do\n> not think it is a clearer term than \"index\" for \"the git index, which\n> contains stat() information and pointers to blobs that either belong\n> in the next commit or are participating in a merge conflict\".  So it\n> does not seem to justify rewriting everything to use it.\n\nWhy should the users care about the stat() information? Or how the\nmerge conflicts are being tracked? That's plumbing, not porcelain.\n\n-- \nFelipe Contreras\n"},{"id":"162334","messageId":"20110227004637.GC20712@elie","threadId":"26489","inReplyTo":"AANLkTimyXciScc5K6ozggMHsy9YmgyOFpy6pgKBEypC9@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-27T00:46:37Z","receivedAt":"2011-02-27T00:46:37Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nFelipe Contreras wrote:\n[out of order for convenience]\n\n> Why should the users care about the stat() information? Or how the\n> merge conflicts are being tracked?\n\nThe second question is very easy to answer (depending on what \"how\"\nmeans, of course). Because people integrating changes from multiple\nplaces need to be able to resolve a conflicted merge.\n\n> That's plumbing, not porcelain.\n\nI don't disagree. The analogy is almost perfect.\n\nAnd the thing is, in the real world, people know about plumbing. They\ndon't care about the details, but they know there are these things\ncalled pipes, and that water tends to flow downward, and that if one\nof them freezes, it will burst. This knowledge is useful.\n\nLikewise, it is useful to know:\n\n - After you use \"cp -a\" to copy a repository, the first operation\n you perform is going to be slower. The cached stat() information\n is stale.\n\n - Until you run \"git add\", there is only one copy of your data, in\n the worktree. After you run \"git add\", there are two copies.\n Once you run \"git commit\", that second copy will last at least\n as long as your commit does.\n\n So there is some chance of recovery from fat-finger mistakes,\n even before a commit.\n\n - During a merge, you can mark your progress by collapsing index\n entries with 'git add'. \"git diff\" will show the state of the\n merge. You can read the competing versions of a file with\n \"git show :2:path/to/file\" and \"git show :3:path/to/file\".\n\n - Index-only operations tend to be faster, since\n\n (1) the cached blobs are not changing, so we can save time\n stat(2)-ing and read(2)-ing files\n (2) blobs are compressed: less I/O. Longstanding blobs are\n in pack files: good caching and I/O patterns.\n\n So you can speed up your slow \"git grep\" by using\n \"git grep --cached\".\n\n - When scripting, you can use a temporary index file to avoid\n affecting the remembered worktree state.\n\nBut so what? I have nothing against clearer terms. I am just saying\nthat (1) we should be explaining these things somewhere and (2) a\nglobal s/index/only one of the things the index does/ is a bad idea,\nbecause it would make the documentation *wrong*.\n\n> There's always resistance, but 1.8 is supposed to contain stuff as \"if\n> git was written from scratch\".\n\nI thought 1.8 was supposed to provide an opportunity to correct some\nlong-known mistakes that we had been holding back on for backward\ncompatibility reasons. That doesn't mean we should forget the cost of\nchange.\n\nThanks for your work, and hope that helps.\nJonathan\n"},{"id":"162340","messageId":"7vzkph6ggw.fsf@alter.siamese.dyndns.org","threadId":"26489","inReplyTo":"AANLkTimyXciScc5K6ozggMHsy9YmgyOFpy6pgKBEypC9@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-27T08:15:27Z","receivedAt":"2011-02-27T08:15:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> There's always resistance, but 1.8 is supposed to contain stuff as \"if\n> git was written from scratch\".\n\nYes, the 1.8.0 is indeed an opportunity to rethink, based on the wisdom we\nhave gained over the years since the current git was written.\n\nIf there has already been a clear consensus that we would have done\nsomething differently if we knew better, it is an opportunity to first\ndiscuss if there is a way to correct these earlier mistakes in a way that\ndoes not have to introduce incompatibility, and if it is not feasible,\ndiscuss a plan to ease incompatible changes in without hurting existing\nusers too much.\n\nA new discussion or proposal is fine, but you should be able to see that\nan effort to start building consensus from now is very much outside the\nscope of the discussion for the 1.8.0 we have been having.\n\nBesides, taking what other people said already in the thread also into\naccount, it looks to me that what you are advocating is too premature to\nbe called a consensus yet.\n"},{"id":"162342","messageId":"20110227084317.GB3356@sigill.intra.peff.net","threadId":"26489","inReplyTo":"AANLkTik-jc0ZX9S4bCYV8VBgPXJZsX0U08W2H+jufO8r@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-27T08:43:17Z","receivedAt":"2011-02-27T08:43:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Feb 26, 2011 at 11:09:14PM +0200, Felipe Contreras wrote:\n\n> On Tue, Feb 15, 2011 at 1:19 AM, Jonathan Nieder wrote:\n> > When people talk about the staging area I tend to get confused.  I\n> > think there's an idea that because it sounds more concrete, there is\n> > less to explain --- or maybe I am just wired the wrong way.\n> \n> I don't like the phrase \"staging area\". A \"stage\" already has an area.\n> You put things on the stage. Sometimes there are multiple stages.\n\nAs a native English speaker, this makes no sense to me. A stage as a\nnoun is either:\n\n 1. a raised platform where you give performances\n\n 2. a phase that some process goes through (e.g., \"the early stages of\n Alzheimer's disease\")\n\nWhereas the term \"staging area\" is a stopping point on a journey for\ncollecting and organizing items. I couldn't find a definite etymology\nonline, but it seems to be military in origin (e.g., you would send all\nyour tanks to a staging area, then once assembled and organized, begin\nyour attack). You can't just call it \"staging\", which is not a noun, and\nthe term \"stage\" is not a synonym. \"Staging area\" has a very particular\nmeaning.\n\nSo the term \"staging area\" makes perfect sense to me; it is where we\ncollect changes to make a commit. I am willing to accept that does not\nto others (native English speakers or no), and that we may need to come\nup with a better term. But I think just calling it \"the stage\" is even\nworse; it loses the concept that it is a place for collecting and\norganizing.\n\n-Peff\n"},{"id":"162347","messageId":"87bp1xest7.fsf@catnip.gol.com","threadId":"26489","inReplyTo":"20110227084317.GB3356@sigill.intra.peff.net","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2011-02-27T09:21:40Z","receivedAt":"2011-02-27T09:21:40Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Jeff King writes:\n> So the term \"staging area\" makes perfect sense to me; it is where we\n> collect changes to make a commit. I am willing to accept that does not\n> to others (native English speakers or no), and that we may need to come\n> up with a better term. But I think just calling it \"the stage\" is even\n> worse; it loses the concept that it is a place for collecting and\n> organizing.\n\nAgreed.\n\n\"Staging area\" is a good noun (phrase) for this. \"Stage\" is a good verb\n(for \"move into the staging area\"), but isn't intuitive as a noun.\n\n-miles\n\n-- \nIn New York, most people don't have cars, so if you want to kill a person, you\nhave to take the subway to their house. And sometimes on the way, the train\nis delayed and you get impatient, so you have to kill someone on the subway.\n [George Carlin]\n"},{"id":"162366","messageId":"1298820612.19827.65.camel@drew-northup.unet.maine.edu","threadId":"26489","inReplyTo":"AANLkTincNdUQ=736=M2Oei4LF0pR0c2T7r=bWJE3RFCu@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2011-02-27T15:30:12Z","receivedAt":"2011-02-27T15:30:12Z","isPatch":false,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Sat, 2011-02-26 at 22:36 +0200, Felipe Contreras wrote:\n> On Thu, Feb 17, 2011 at 1:11 AM, Drew Northup wrote:\n> >\n> > On Sun, 2011-02-13 at 19:09 -0800, Pete Harlan wrote:\n> >> On 02/13/2011 02:58 PM, Junio C Hamano wrote:\n> >> >> --staged\n> >> >> ~~~~~~~~\n> >> >> diff takes --staged, but that is only to support some people's habits.\n> >> > The term \"stage\" comes from \"staging area\", a term people used to explain\n> >> > the concept of the index by saying \"The index holds set of contents to be\n> >> > made into the next commit; it is _like_ the staging area\".\n> >> >\n> >> > My feeling is that \"to stage\" is primarily used, outside \"git\" circle, as\n> >> > a logistics term. If you find it easier to visualize the concept of the\n> >> > index with \"staging area\" (\"an area where troops and equipment in transit\n> >> > are assembled before a military operation\", you may find it easier to say\n> >> > \"stage this path ('git add path')\", instead of \"adding to the set of\n> >> > contents...\".\n> >>\n> >> FWIW, when teaching Git I have found that users immediately understand\n> >> \"staging area\", while \"index\" and \"cache\" confuse them.\n> >>\n> >> \"Index\" means to them a numerical index into a data structure.\n> >> \"Cache\" is a local copy of something that exists remotely. Neither\n> >> word describes the concept correctly from a user's perspective.\n> >\n> > According to the dictionary (actually, more than one) \"cache\" is a\n> > hidden storage space. I'm pretty sure that's the sense most global and\n> > therefore most appropriate to thinking about Git. (It certainly\n> > describes correctly what web browser cache and on-CPU cache is doing.)\n> > One would only think the definition you gave applied if they didn't know\n> > that squirrels \"cache\" nuts. I don't think that the problem is the\n> > idiom.\n> \n> Not really. If a squirrel \"caches\" nuts, it means a squirrel is\n> putting them in a hidden place to save them for future use. So, in the\n> future, if said squirrel wants a nut, it doesn't have to look for it\n> in the trees, just go to the cache. So the cache makes it easier to\n> access whatever your want.\n> \n> IOW; if you don't cache something, you would have more trouble getting\n> it, but you still can.\n> \n> That's not what Git is doing. Git is not putting changes in a place so\n> the can be more easily accessed in the future. It is using a temporary\n> device that allows the commit to be built through an extended period\n> of time. It's not a cache.\n\nAs I noted earlier, \"cache\" classically has nothing whatsoever to do\nwith temporality, it is a descriptor of visibility. Any notion of\ntemporality or intentionality is imposed by the reader. THAT'S THE\nPROBLEM. \n\n> >> I learned long ago to type \"index\" and \"cached\", but when talking (and\n> >> thinking) about Git I find \"the staging area\" gets the point across\n> >> very clearly and moves Git from interesting techie-tool to\n> >> world-dominating SCM territory. I'm surprised that that experience\n> >> isn't universal.\n> >\n> > Perhaps that helps you associate it with other SCM/VCS software, but it\n> > didn't help me. When I realized that the \"index\" is called that BECAUSE\n> > IT IS AN INDEX (of content/data states for a pending commit operation)\n> > the sky cleared and the sun came out.\n> \n> That's not an index. An index is a guide of pointers to something\n> else. It allows you to find whatever you are looking for by looking in\n> small table of pointers instead of looking through all the samples.\n> \n> IOW; if you don't index something, you would have more trouble finding\n> it, but you still can.\n> \n> That's not what Git is doing.\n\nIndex: \"That which guides, points out, informs, or directs\" [1913\nEdition Webster's Dictionary--new one says something pretty similar if\nnot the same].\nAs far as I can tell Git is using the \"Index\" to do just that. Again, I\nam discarding all notions of connotation here and focusing solely on the\ndenotation of the word. Besides, it is still possible to build a commit\nwith git without the \"Index\"; it is a real royal pain--and not the least\nadvisable for day-to-day use.\n\n> > In all reality the closest thing Git has to an actual staging area is\n> > all of the objects in .git/objects only recorded by the index itself.\n> > Git-stored objects not compressed into pack files could technically be\n> > described as \"cached\" using the standard definition--they aren't visible\n> > in the working directory. Unfortunately this probably just muddies the\n> > water for all too many users.\n> \n> That's irrelevant. You can implement the same functionality in many\n> other ways. How it is implement doesn't matter, what matters is what\n> the user experiences.\n\nPlease re-read what I said, more slowly and without notion of previous\ndisagreement if you can muster it. We both agree that the notion of\ncaching here is superfluous to most users. Alas, I am not one to say\nthat what any one user experiences should dictate to us who all users\nSHOULD experience Git. It is fairly clear to me that isn't what is\ncurrently happening and any efforts to force the matter thus far haven't\nhelped matters much if at all.\n\n> > So, in summary--the index is real, objects \"cached\" pending\n> > commit/cleanup/packing are real; any \"staging area\" is a rhetorical\n> > combination of the two. Given that rhetorical device may not work in all\n> > languages (as Junio mentioned earlier) I don't recommend that we rely on\n> > it.\n> \n> Branches and tags are \"rthetorical\" devices as well. But behind scenes\n> they are just refs. Shall we disregard 'branch' and 'tag'?\n> \n> No. What Git does behind scenes is irrelevant to the user. What\n> matters is what the device does, not how it is implemented; the\n> implementation might change. \"Stage\" is the perfect word; both verb\n> and a noun that express a temporary space where things are prepared\n> for their final form.\n\nYes they (branches and tags) are. They also have a \"physical\"\nmanifestation. A \"staging area\" does not. This obviously is of little\nimportance to you (as a user--I know you do more than that), but would\nmatter a great deal to somebody like myself currently mulling over how\nto craft a contribution to this project.\n\nAlas, as Junio pointed out earlier, \"stage\" is a metaphor of limited\nutility (it also means a large number of things in English alone--I tend\nto think of theaters and not states when I read it). In fact, it opens\nup more questions: \"Staged where? In a cache. Where is the cache? It\ndoesn't really exist, but it is a combination of the Index and\nunder-referenced objects in the object store acting as a cache. Why? How\ndoes it do that?.....\" We are therefore where we started. Users are just\nas confused as they were before, and we're looking for a good watering\nhole to cluster at and come up with a better way to explain it without\ngetting into the gritty details.\n\nDetails sometimes matter, sometimes they don't, and much more often the\nreality is halfway between the two. Currently I think that Git is in\nthat middle state. Discarding outright the notion of the Index and of\ncaching doesn't make sense (as, at some level, that's what's happening),\nyet staging isn't perfect either. That's my point.\n\n(Please also see my pending reply to Jeff's missive from 8:43 UTC\ntoday.)\n\n-- \n-Drew Northup\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"162367","messageId":"1298820840.19827.69.camel@drew-northup.unet.maine.edu","threadId":"26489","inReplyTo":"20110227084317.GB3356@sigill.intra.peff.net","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2011-02-27T15:34:00Z","receivedAt":"2011-02-27T15:34:00Z","isPatch":false,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Sun, 2011-02-27 at 03:43 -0500, Jeff King wrote:\n> On Sat, Feb 26, 2011 at 11:09:14PM +0200, Felipe Contreras wrote:\n> \n> > On Tue, Feb 15, 2011 at 1:19 AM, Jonathan Nieder wrote:\n> > > When people talk about the staging area I tend to get confused. I\n> > > think there's an idea that because it sounds more concrete, there is\n> > > less to explain --- or maybe I am just wired the wrong way.\n> > \n> > I don't like the phrase \"staging area\". A \"stage\" already has an area.\n> > You put things on the stage. Sometimes there are multiple stages.\n> \n> As a native English speaker, this makes no sense to me. A stage as a\n> noun is either:\n> \n> 1. a raised platform where you give performances\n> \n> 2. a phase that some process goes through (e.g., \"the early stages of\n> Alzheimer's disease\")\n\nI definitely appreciate this notion. The equivalence of \"stage ===\nstatus of something, given place and or time\" is itself metaphorical in\nnature. I don't know how translatable the idiom is.\n\n> Whereas the term \"staging area\" is a stopping point on a journey for\n> collecting and organizing items. I couldn't find a definite etymology\n> online, but it seems to be military in origin (e.g., you would send all\n> your tanks to a staging area, then once assembled and organized, begin\n> your attack). You can't just call it \"staging\", which is not a noun, and\n> the term \"stage\" is not a synonym. \"Staging area\" has a very particular\n> meaning.\n\nI would have to check, but I believe you would find it linked to\nmetaphorical language about the \"stage on which a battle is\nfought\" (battleground) and the fact that forces are sometimes organized\ninto formation--as they would appear upon a stage--in such an area\n(before a parade or a march, for instance).\n\n> So the term \"staging area\" makes perfect sense to me; it is where we\n> collect changes to make a commit. I am willing to accept that does not\n> to others (native English speakers or no), and that we may need to come\n> up with a better term. But I think just calling it \"the stage\" is even\n> worse; it loses the concept that it is a place for collecting and\n> organizing.\n> \n> -Peff\n\nThe concept of a \"staging area\" is definitely of limited use for many of\nus attempting to learn how git works. The very fact that the object\ncache and the Index (or multiple, as is useful at times) are distinct\nelements is useful and should be mentioned somewhere. Alas, creating in\nthe user's mind that there is a distinct unified \"staging area\" acts\nagainst this dissemination of knowledge. It definitely didn't help me.\n\nIf we use \"staging area made up of the object store and information kept\nin the Index\" then we tie a knot on everything, make it clear that it\nmay be more complex than that--and you don't have to care, and we do not\nforeclose on the possibility of more complete explanation later. That\ndoes not bother me. We do however need to recognize that \"staging area\"\nis an idiom of limited portability and deal with that appropriately. \n\nA particular Three Stooges episode comes to mind here for me. The Three,\nin one scene, are getting dressed up to go to an estate (a relative of\none of them has died) to collect an inheritance. They are jumping up and\ndown yelling \"We're gonna get rich!\" in the English original. However,\nthe only thing the only timing appropriate thing the translator could\nthink of when producing the Spanish voice-over was \"Vamos a\nvestirse\" (we're going to get dressed). Obviously this made them seem\nlike more utter fools than the were, but equally obviously the meaning\nof the idiom \"gonna get rich\" was lost on the translator. This is what\nhas been replaying in my mind since Junio brought up the limited\nportability of the notion of a \"staging area\" a little while back. He's\nright--many idioms do not not survive translation. This is why we need\nto make the documentation robust and technically correct while also\nattempting to be nice to new users.\n\n-- \n-Drew Northup\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"162377","messageId":"4D6A9C1C.5000907@cisco.com","threadId":"26489","inReplyTo":"AANLkTik-jc0ZX9S4bCYV8VBgPXJZsX0U08W2H+jufO8r@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Phil Hord","fromEmail":"hordp@cisco.com","sentAt":"2011-02-27T18:46:52Z","receivedAt":"2011-02-27T18:46:52Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On 02/26/2011 04:09 PM, Felipe Contreras wrote:\n> I don't like the phrase \"staging area\". A \"stage\" already has an area.\n> You put things on the stage. Sometimes there are multiple stages.\n\nA \"staging area\" (idiomatically, perhaps) is a location where things are\ncollected to be organized before deployment. Sounds a lot like our index.\n\nhttp://en.wikipedia.org/wiki/Staging_area\n\n> If only a subset of the files are there, it's an 'index', if not, then\n> I'd say it's a 'registry'. Anyway, it's something the user shouldn't\n> care about.\n\nWhen we pack up our kayak club for a trip, we stage equipment we're\nbringing. Eventually we make a decision about which equipment is going\nand which is staying. The decision is codified by the equipment we\nleave in the staging area versus the equipment we remove to local\nstorage. Everyone seems to understand the term when we use it in this\ncontext.\n\nI think the parade analogy is also pretty common.\n\nI like \"staging area(n)/stage(v)\" better than \"index\" or \"cache\" because\nof the connotation in English. But if it doesn't translate well, the\nsearch may need to go on. Maybe we can fall back on stdc methods and\ninvent generic terms like strcpy. How about \"xnar\"?\n\nPhil\n"},{"id":"162384","messageId":"AANLkTik3rV6vejf=aRvysvxr4qn_UJxUqiQiTB0AG-vp@mail.gmail.com","threadId":"26489","inReplyTo":"4D589CE0.7020203@pcharlan.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Aghiles","fromEmail":"aghilesk@gmail.com","sentAt":"2011-02-27T21:16:40Z","receivedAt":"2011-02-27T21:16:40Z","isPatch":false,"sender":{"key":"aghilesk@gmail.com","avatar":null},"body":"> FWIW, when teaching Git I have found that users immediately understand\n> \"staging area\", while \"index\" and \"cache\" confuse them.\n\nFWIW, same here.\n\n-- aghiles\n"},{"id":"162385","messageId":"AANLkTinphmVJe8XW6BhjoyHgA38aopgEk=o=qEp4UT+4@mail.gmail.com","threadId":"26489","inReplyTo":"87bp1xest7.fsf@catnip.gol.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-02-27T22:28:07Z","receivedAt":"2011-02-27T22:28:07Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Sun, Feb 27, 2011 at 8:21 PM, Miles Bader wrote:\n> Jeff King writes:\n>> So the term \"staging area\" makes perfect sense to me; it is where we\n>> collect changes to make a commit. I am willing to accept that does not\n>> to others (native English speakers or no), and that we may need to come\n>> up with a better term. But I think just calling it \"the stage\" is even\n>> worse; it loses the concept that it is a place for collecting and\n>> organizing.\n>\n> Agreed.\n>\n> \"Staging area\" is a good noun (phrase) for this.  \"Stage\" is a good verb\n> (for \"move into the staging area\"), but isn't intuitive as a noun.\n>\n\nWhen used to describe a pre-production environment, the noun in my experience\nis inevitably 'staging' (short for staging environment) rather than\n'stage' which\nis consistent with the origin Jeff posits.\n\nI guess the noun 'stage' does have a use in git-speak to refer to the\ndifferent arms of\nan unresolved merge.\n\njon.\n"},{"id":"162391","messageId":"7vmxlhm3ne.fsf@alter.siamese.dyndns.org","threadId":"26489","inReplyTo":"AANLkTinphmVJe8XW6BhjoyHgA38aopgEk=o=qEp4UT+4@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-27T23:57:57Z","receivedAt":"2011-02-27T23:57:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Seymour writes:\n\n> I guess the noun 'stage' does have a use in git-speak to refer to the\n> different arms of an unresolved merge.\n\nThat is correct.\n\nFor some historical background around \"cache\" and \"index\", this\n\n http://thread.gmane.org/gmane.comp.version-control.git/780/focus=924\n\nmay shed some light.\n\n From: Linus Torvalds \n Subject: Re: [RFC] Possible strategy cleanup for git add/remove/diff etc.\n Date: Tue, 19 Apr 2005 18:51:06 -0700 (PDT)\n Message-ID: \n\n That is indeed the whole point of the index file. In my world-view, the\n index file does _everything_. It's the staging area (\"work file\"), it's\n the merging area (\"merge directory\") and it's the cache file (\"stat\n cache\").\n\nAnd this one:\n\n http://thread.gmane.org/gmane.comp.version-control.git/6670/focus=6863\n\nis even more illuminating.\n\nNotice that the word \"staging area\" is used in the old article as a way to\nexplain one of the three important aspects of the index, and the other\narticle that is about nailing down the terminology, the word does not even\ncome into the picture at all (one reason being that it will confuse\nreaders if \"staging area\" is used too casually in a document to precisely\ndefine terminology, which needs to explain the merge stage(s) in the\nindex).\n"},{"id":"162414","messageId":"4D6B6D0B.3040304@drmicha.warpmail.net","threadId":"26489","inReplyTo":"7vmxlhm3ne.fsf@alter.siamese.dyndns.org","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-02-28T09:38:19Z","receivedAt":"2011-02-28T09:38:19Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 28.02.2011 00:57:\n> Jon Seymour writes:\n> \n>> I guess the noun 'stage' does have a use in git-speak to refer to the\n>> different arms of an unresolved merge.\n> \n> That is correct.\n> \n> For some historical background around \"cache\" and \"index\", this\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/780/focus=924\n> \n> may shed some light.\n> \n> From: Linus Torvalds \n> Subject: Re: [RFC] Possible strategy cleanup for git add/remove/diff etc.\n> Date: Tue, 19 Apr 2005 18:51:06 -0700 (PDT)\n> Message-ID: \n> \n> That is indeed the whole point of the index file. In my world-view, the\n> index file does _everything_. It's the staging area (\"work file\"), it's\n> the merging area (\"merge directory\") and it's the cache file (\"stat\n> cache\").\n> \n> And this one:\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/6670/focus=6863\n> \n> is even more illuminating.\n> \n> Notice that the word \"staging area\" is used in the old article as a way to\n> explain one of the three important aspects of the index, and the other\n> article that is about nailing down the terminology, the word does not even\n> come into the picture at all (one reason being that it will confuse\n> readers if \"staging area\" is used too casually in a document to precisely\n> define terminology, which needs to explain the merge stage(s) in the\n> index).\n\nOh, the classics :)\n\nThanks for an illuminating and entertaining read!\n\nMichael\n"},{"id":"162472","messageId":"1298926426.29337.5.camel@drew-northup.unet.maine.edu","threadId":"26489","inReplyTo":"AANLkTik3rV6vejf=aRvysvxr4qn_UJxUqiQiTB0AG-vp@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2011-02-28T20:53:46Z","receivedAt":"2011-02-28T20:53:46Z","isPatch":false,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Sun, 2011-02-27 at 16:16 -0500, Aghiles wrote:\n> > FWIW, when teaching Git I have found that users immediately understand\n> > \"staging area\", while \"index\" and \"cache\" confuse them.\n> \n> FWIW, same here.\n\nI would really like to hear the actual presentation. What one says in\nperson in front of a classroom and what one puts in a manpage are\nfrequently not the same thing--and there's a good reason for that. \nIf nothing else, we could come up with a better presentation at the end!\n\n-- \n-Drew Northup\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"162489","messageId":"20110228230311.GA7533@sigill.intra.peff.net","threadId":"26489","inReplyTo":"1298820840.19827.69.camel@drew-northup.unet.maine.edu","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-28T23:03:11Z","receivedAt":"2011-02-28T23:03:11Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 27, 2011 at 10:34:00AM -0500, Drew Northup wrote:\n\n> The concept of a \"staging area\" is definitely of limited use for many of\n> us attempting to learn how git works. The very fact that the object\n> cache and the Index (or multiple, as is useful at times) are distinct\n> elements is useful and should be mentioned somewhere.\n\nNow your terminology has _me_ confused. What is the \"object cache\"?\n\n> Alas, creating in the user's mind that there is a distinct unified\n> \"staging area\" acts against this dissemination of knowledge. It\n> definitely didn't help me.\n\nI'm not sure what you mean by \"distint unified staging area\". It is a\nconceptual idea that you will put your changes somewhere, and when they\nlook good to you, then you will finalize them in some way.\n\nBut note that it is a mental model. The fact that it is implemented\ninside the index, along with the stat cache, doesn't need to be relevant\nto the user. And the fact that the actual content is in the object\nstore, with sha1-identifiers in the index, is not relevant either. At\nleast I don't think so, and I am usually of the opinion that we should\nexpose the data structures to the user, so that their mental model can\nmatch what is actually happening. But in this case, I think they can\nstill have a pretty useful but simpler mental model.\n\n> If we use \"staging area made up of the object store and information kept\n> in the Index\" then we tie a knot on everything, make it clear that it\n> may be more complex than that--and you don't have to care, and we do not\n> foreclose on the possibility of more complete explanation later. That\n> does not bother me. We do however need to recognize that \"staging area\"\n> is an idiom of limited portability and deal with that appropriately.\n\nSure, I'm willing to accept that the specific words of the idiom aren't\ngood for people with different backgrounds.\n\nOne analogy I like for the index is that it's a bucket. It starts out\nfull of files from the last commit. You can put new, changed files in\nthe bucket. When it looks good, you dump the bucket into a commit. You\ncan have multiple buckets if you want. You can pull files from other\ncommits and put them in the bucket. You can take files out of the bucket\nand put them in your work tree.\n\nSo maybe it should just be called \"the bucket\"?\n\nI'm not sure that's a good idea, because while the analogy makes sense,\nit doesn't by itself convey any meaning. That is, knowing the concept, I\ncan see that bucket is a fine term. But hearing about git's bucket, I\nhave no clue what it means. Whereas \"staging area\" I think is a bit more\nspecific, _if_ you know what a staging area is.\n\nSo there are two questions:\n\n 1. Is there a more universal term that means something like \"staging\n area\"?\n\n 2. Is the term \"staging area\", while meaningful to some, actually\n _worse_ to others than a term like \"bucket\"? That is, does it sound\n complex and scary, when it is really a simple thing. And while\n people won't know what the \"git bucket\" is off the bat, it is\n relatively easy to learn.\n\n And obviously, replace \"bucket\" here with whatever term makes more\n sense.\n\n> A particular Three Stooges episode comes to mind here for me.\n\nWow, 180,000 messages and this is somehow the first Three Stooges\nanalogy on the git list.\n\n-Peff\n"},{"id":"162521","messageId":"4D6CB1B3.1010005@terreactive.ch","threadId":"26489","inReplyTo":"878466.93199.1298934204331.JavaMail.trustmail@mail1.terreactive.ch","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Victor Engmark","fromEmail":"victor.engmark@terreactive.ch","sentAt":"2011-03-01T08:43:31Z","receivedAt":"2011-03-01T08:43:31Z","isPatch":false,"sender":{"key":"victor.engmark@terreactive.ch","avatar":null},"body":"On 03/01/2011 12:03 AM, Jeff King wrote:\n> On Sun, Feb 27, 2011 at 10:34:00AM -0500, Drew Northup wrote:\n\n> One analogy I like for the index is that it's a bucket. It starts out\n> full of files from the last commit. You can put new, changed files in\n> the bucket. When it looks good, you dump the bucket into a commit. You\n> can have multiple buckets if you want. You can pull files from other\n> commits and put them in the bucket. You can take files out of the bucket\n> and put them in your work tree.\n> \n> So maybe it should just be called \"the bucket\"?\n> \n> I'm not sure that's a good idea, because while the analogy makes sense,\n> it doesn't by itself convey any meaning. That is, knowing the concept, I\n> can see that bucket is a fine term. But hearing about git's bucket, I\n> have no clue what it means. Whereas \"staging area\" I think is a bit more\n> specific, _if_ you know what a staging area is.\n> \n> So there are two questions:\n> \n> 1. Is there a more universal term that means something like \"staging\n> area\"?\n> \n> 2. Is the term \"staging area\", while meaningful to some, actually\n> _worse_ to others than a term like \"bucket\"? That is, does it sound\n> complex and scary, when it is really a simple thing. And while\n> people won't know what the \"git bucket\" is off the bat, it is\n> relatively easy to learn.\n\nI like the name \"git bucket\", as in \"a git bit bucket\", but semantically\nthe connection is just \"a container\". Especially for beginners this can\nresult in the wrong connotations:\n* Limited size. A modern harddisk is vastly larger than most Git\nrepositories, likening it more to a container ship than a bucket.\n* Definite size. Harddisk space availability varies with time, unlike\nmost containers.\n* Non-linear use. A full physical bucket could be used for many\ndifferent things, but a full git bucket can either be forgotten (with\ncheckout), remembered temporarily (with stash), or remembered\npermanently (with commit).\n* Container-specific features irrelevant for git: Handles, translucency\n(or not), depth, material, dimensions of the opening...\n\nHow about a metaphor like \"plan\"? You either cancel/undo it (git\ncheckout), postpone / shelf it (git stash), resume/continue it (git\nstash apply) or commit to it. Coming from the desktop metaphor, I\npersonally like `git undo`, `git postpone/resume` and `git commit` -\nThey give a clear sense of direction towards the commit, and much\nclearer verbs for those new to VC in general.\n\n-- \nVictor Engmark\n"},{"id":"162524","messageId":"AANLkTi=LPqu9zDiAJpxqC=ZCLig+aCv5ztXw668ERtH7@mail.gmail.com","threadId":"26489","inReplyTo":"20110228230311.GA7533@sigill.intra.peff.net","subject":"Re: Consistent terminology: cached/staged/index","fromName":"David","fromEmail":"bouncingcats@gmail.com","sentAt":"2011-03-01T09:11:11Z","receivedAt":"2011-03-01T09:11:11Z","isPatch":false,"sender":{"key":"bouncingcats@gmail.com","avatar":null},"body":"On 1 March 2011 10:03, Jeff King wrote:\n> On Sun, Feb 27, 2011 at 10:34:00AM -0500, Drew Northup wrote:\n>\n> I'm not sure what you mean by \"distint unified staging area\". It is a\n> conceptual idea that you will put your changes somewhere, and when they\n> look good to you, then you will finalize them in some way.\n>\n> But note that it is a mental model. The fact that it is implemented\n> inside the index, along with the stat cache, doesn't need to be relevant\n> to the user. And the fact that the actual content is in the object\n> store, with sha1-identifiers in the index, is not relevant either. At\n> least I don't think so, and I am usually of the opinion that we should\n> expose the data structures to the user, so that their mental model can\n> match what is actually happening. But in this case, I think they can\n> still have a pretty useful but simpler mental model.\n>\n>> If we use \"staging area made up of the object store and information kept\n>> in the Index\" then we tie a knot on everything, make it clear that it\n>> may be more complex than that--and you don't have to care, and we do not\n>> foreclose on the possibility of more complete explanation later. That\n>> does not bother me. We do however need to recognize that \"staging area\"\n>> is an idiom of limited portability and deal with that appropriately.\n>\n> Sure, I'm willing to accept that the specific words of the idiom aren't\n> good for people with different backgrounds.\n>\n> One analogy I like for the index is that it's a bucket. It starts out\n> full of files from the last commit. You can put new, changed files in\n> the bucket. When it looks good, you dump the bucket into a commit. You\n> can have multiple buckets if you want. You can pull files from other\n> commits and put them in the bucket. You can take files out of the bucket\n> and put them in your work tree.\n>\n> So maybe it should just be called \"the bucket\"?\n>\n> I'm not sure that's a good idea, because while the analogy makes sense,\n> it doesn't by itself convey any meaning. That is, knowing the concept, I\n> can see that bucket is a fine term. But hearing about git's bucket, I\n> have no clue what it means. Whereas \"staging area\" I think is a bit more\n> specific, _if_ you know what a staging area is.\n>\n> So there are two questions:\n>\n>  1. Is there a more universal term that means something like \"staging\n>     area\"?\n>\n>  2. Is the term \"staging area\", while meaningful to some, actually\n>     _worse_ to others than a term like \"bucket\"? That is, does it sound\n>     complex and scary, when it is really a simple thing. And while\n>     people won't know what the \"git bucket\" is off the bat, it is\n>     relatively easy to learn.\n>\n>     And obviously, replace \"bucket\" here with whatever term makes more\n>     sense.\n\nA suggestion: could your conceptual bucket be named as \"the precommit\".\n\nMotives for this suggestion are:\n1) I imagine this word will be readily translatable;\n2) Using an invented word like this neatly avoids the complication of\nthe various different connotations associated with existing words like\n\"index\", \"cache\", and \"stage\" that others have raised.\n\nThe \"precommit\" would be a user concept that merely specifies the\ncontent of the next commit. Its purpose is to simplify the user\ninterface and the documentation. For example, man git-status would\nread like this:\n\n\"git status displays paths that have differences between the precommit\nand the current HEAD commit, paths that have differences between the\nworking tree and the precommit, and paths in the working tree that are\nnot tracked by git.\"\n\nThe \"precommit\" is not to be associated to any specific data structure\nin the implementation. For users who want more understanding, it can\nbe explained that the precommit is implemented by a combination of\ndata structures. Which are then free to be named anything appropriate\nto their individual function (eg \"the index file\") without triggering\nall the issues that give rise to this thread.\n"},{"id":"162526","messageId":"vpqaahf9p69.fsf@bauges.imag.fr","threadId":"26489","inReplyTo":"AANLkTi=LPqu9zDiAJpxqC=ZCLig+aCv5ztXw668ERtH7@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-03-01T09:15:58Z","receivedAt":"2011-03-01T09:15:58Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"David writes:\n\n> A suggestion: could your conceptual bucket be named as \"the\n> precommit\".\n\nI actually like it.\n\nMaybe \"precommit area\", or \"precommit something\", because \"precommit\"\ncould be seen either as an action (like the pre-commit hook) or as a\nplace to put stuff.\n\nAs a non-native speaker, I didn't know what \"staging area\" really meant\nin english, but the \"area\" part of the expression immediately made sense\nto me. Had it been called the \"foobar-ing area\", I would have found it\nmore intuitive than cache or index ;-).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"162529","messageId":"op.vrnq8gk856e9f9@xman.eng.oslo.osa","threadId":"26489","inReplyTo":"AANLkTi=LPqu9zDiAJpxqC=ZCLig+aCv5ztXw668ERtH7@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Alexey Feldgendler","fromEmail":"alexeyf@opera.com","sentAt":"2011-03-01T09:27:58Z","receivedAt":"2011-03-01T09:27:58Z","isPatch":false,"sender":{"key":"alexeyf@opera.com","avatar":null},"body":"On Tue, 01 Mar 2011 10:11:11 +0100, David wrote:\n\n> A suggestion: could your conceptual bucket be named as \"the precommit\".\n>\n> Motives for this suggestion are:\n> 1) I imagine this word will be readily translatable;\n\nLess so than “staging area”, at least into Russian.\n\nJust my two cents.\n\n\n-- \nAlexey Feldgendler\nSoftware Developer, Desktop Team, Opera Software ASA\n[ICQ: 115226275] http://my.opera.com/feldgendler/\n"},{"id":"162530","messageId":"AANLkTi=sXLcVJRVH87jXvVwCth+8vGgc7Ha0=XEG0Kx4@mail.gmail.com","threadId":"26489","inReplyTo":"vpqaahf9p69.fsf@bauges.imag.fr","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Alexei Sholik","fromEmail":"alcosholik@gmail.com","sentAt":"2011-03-01T09:32:00Z","receivedAt":"2011-03-01T09:32:00Z","isPatch":false,"sender":{"key":"alcosholik@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207748?v=4"},"body":"On 1 March 2011 11:15, Matthieu Moy wrote:\n> David writes:\n>\n>> A suggestion: could your conceptual bucket be named as \"the\n>> precommit\".\n>\n> ...\n>\n> As a non-native speaker, I didn't know what \"staging area\" really meant\n> in english, but the \"area\" part of the expression immediately made sense\n> to me. Had it been called the \"foobar-ing area\", I would have found it\n> more intuitive than cache or index ;-).\n\nHello everyone,\nI'm not a very experienced git-user and I still remember how it felt\nwhen I started learning git. I don't recall the exact tutorial I used\n(probably it was the 'Pro Git' Book), but anyway, it used the term\n\"staging area\" and \"to stage changes\" from the outset. I'm also not a\nnative English speaker and I hadn't even heard of the term \"to stage\"\nbefore, but managed to grasp at once what \"to stage changes\" meant.\n\nAs of such names as \"bucket\" and \"precommit\", I don't think they will\ndo. There is a lot of resources for beginners on the internet already,\nmany of them already use \"staging area\" and \"index\". There's no need\nto rename the staging area. The only source of confusion as I see it\ncomes from the interchangeable usage of the terms \"staging area\" and\n\"index\" (\"staged\" and \"cached\" being the other confusing pair of\nwords).\n\nI guess, people who are friendly with git using the word \"index\"\nbecause it's easier to type. But it confuses an unprepared reader. The\nsolution of the problem with confusion must be relevant to these\npoints:\n - clarify that \"index\" means the same thing as the \"staging area\" (in\nman if it isn't there already?)\n - replace \"cached\" with \"staged\" for consistency with the term\n\"staging area\" (I guess none of you would like to replace ot with\n\"indexed\" instead :-P)\n\nBest regards,\nAlexei Sholik\n"},{"id":"162537","messageId":"20110301102903.GA31176@elie","threadId":"26489","inReplyTo":"AANLkTi=9OWqz66Ab6O9tc4eYSrhZZ1YC_+ta9sutAn30@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-03-01T10:29:03Z","receivedAt":"2011-03-01T10:29:03Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi again,\n\nPiotr Krukowiecki wrote:\n\n> is there a plan for using one term\n\nTo summarize: everyone knows what the staging area is, no one seems to\nknow what the index is, and the --cached options are confusing.\n\nWe need a new description (terminology, or better yet, story) for\n\"git's view of the work tree\", since just saying \"the index! the\nindex!\" without a myth behind it confuses people.\n\nVarious commands take --cached (porcelain):\n\n. git diff --cached\t- view staged changes relative to the named tree.\n. git grep --cached\t- search in the staging area instead of the worktree.\n. git rm --cached\t- only remove from the index.\n\n(plumbing):\n\n. git apply --cached\t- apply a patch without touching the worktree.\n. git ls-files --cached\t- list paths that will have content in the next commit.\n\nIt would be reasonable to introduce a synonym --index-only. That can\nbe confusing if you don't view the staging area as representing git's\ndeluded idea of what's in the work tree, though. For the same reason\nand some others, --no-worktree / --ignore-worktree wouldn't work so\nwell (e.g., \"git ls-files --no-worktree\" would be terribly confusing).\nSo, um, we're stuck?\n\nVarious commands take --index or related options (porcelain):\n\n. git filter-branch --index-filter\t- let hook tweak index before commit\n. git stash apply --index\t- revive the stashed index changes, too\n. git stash save --keep-index\t- do not stash changes already added to index\n\n(toys):\n\n. git grep --no-index\t- just act as a better \"grep\"; do not look for .git\n. git diff --no-index\t- just act as a better \"diff\"; do not look for .git\n\n(plumbing):\n\n. git apply --index\t- next commit will have the patch applied, too\n. git checkout-index --index\t- update stat() cache while at it\n. git read-tree --index-output\t- write output to a different index file\n. git update-index --index-info\t- apply changes in ls-tree or ls-files format\n. GIT_INDEX_FILE\t- where information about the worktree goes\n\nIt would be possible to introduce synonyms along the lines of\nGIT_STAGING_AREA_FILE, keeping in mind that they also affect the\nmerging process (and some of them also affect the stat() cache), if\nthat seems like the right thing to do.\n"},{"id":"162557","messageId":"1298997963.5247.30.camel@drew-northup.unet.maine.edu","threadId":"26489","inReplyTo":"op.vrnq8gk856e9f9@xman.eng.oslo.osa","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2011-03-01T16:46:03Z","receivedAt":"2011-03-01T16:46:03Z","isPatch":false,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Tue, 2011-03-01 at 10:27 +0100, Alexey Feldgendler wrote:\n> On Tue, 01 Mar 2011 10:11:11 +0100, David wrote:\n> \n> > A suggestion: could your conceptual bucket be named as \"the precommit\".\n> >\n> > Motives for this suggestion are:\n> > 1) I imagine this word will be readily translatable;\n> \n> Less so than “staging area”, at least into Russian.\n> \n> Just my two cents.\n\nI was starting to think about \"commit preparation area\" this morning,\nbut it sounds horribly long. Would \"Prep area\" work provided that the\nlonger version has already been introduced into the discussion? This\nprovides a similar language metaphor to \"staging area\" hopefully without\nthe translation problem.\n\nAlso, I still think that it is important to note somewhere that the way\nthat git handles commits is not the way that most users are likely to\nimagine (the Index doesn't contain the blob objects itself; a finalized\ncommit is not just a bundled collection of everything as somebody might\nexpect; etc) so this \"Prep area\" is a logical space not completely\nanalogous to stuff found in the \".git\" directory. Pretending that\ncomplexity does not exist will not help; letting the users know that\nthey don't need to grok all of the details to get started is, on the\nother hand, quite important.\n\n(Reconstructing the CC list... let me know if I left you out, spammed\nyou, etc...)\n\n-- \n-Drew Northup\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"162558","messageId":"1298998965.5247.46.camel@drew-northup.unet.maine.edu","threadId":"26489","inReplyTo":"AANLkTi=sXLcVJRVH87jXvVwCth+8vGgc7Ha0=XEG0Kx4@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2011-03-01T17:02:45Z","receivedAt":"2011-03-01T17:02:45Z","isPatch":false,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Tue, 2011-03-01 at 11:32 +0200, Alexei Sholik wrote:\n\n> I guess, people who are friendly with git using the word \"index\"\n> because it's easier to type. But it confuses an unprepared reader. The\n> solution of the problem with confusion must be relevant to these\n> points:\n> - clarify that \"index\" means the same thing as the \"staging area\" (in\n> man if it isn't there already?)\n\nAlas, this isn't quite true. Blobs are copied to the .git/objects\ndirectory (which I referred to earlier as an object store without proper\nqualification) with each \"git add\" action AND are noted in the Index at\nthe same time. Therefore the Index is quite literally containing\ninformation about the blobs to be committed without containing the blobs\nthemselves. This is why I find any specific equivalence between Index\nand \"staging area\" distasteful--it is misleading. \n\n(Yes, I made that mistake as well--helped along by a lot of third-party\ndocumentation referring to a specific cache or a specific \"staging area\"\nwithout noting that those were tools to understand the logical function\nof git but did not have anything to do with implementation. When you\nclaim to be explaining \"how something works\" you should be doing just\nthat.)\n\n-- \n-Drew Northup\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"162560","messageId":"AANLkTikCEoc55WuiRNo6Q=sXqTd_WDfVRb6cnN5bRD=0@mail.gmail.com","threadId":"26489","inReplyTo":"1298998965.5247.46.camel@drew-northup.unet.maine.edu","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Alexei Sholik","fromEmail":"alcosholik@gmail.com","sentAt":"2011-03-01T17:30:41Z","receivedAt":"2011-03-01T17:30:41Z","isPatch":false,"sender":{"key":"alcosholik@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207748?v=4"},"body":"On 1 March 2011 19:02, Drew Northup wrote:\n>\n> On Tue, 2011-03-01 at 11:32 +0200, Alexei Sholik wrote:\n>\n>> I guess, people who are friendly with git using the word \"index\"\n>> because it's easier to type. But it confuses an unprepared reader. The\n>> solution of the problem with confusion must be relevant to these\n>> points:\n>>  - clarify that \"index\" means the same thing as the \"staging area\" (in\n>> man if it isn't there already?)\n>\n> Alas, this isn't quite true. Blobs are copied to the .git/objects\n> directory (which I referred to earlier as an object store without proper\n> qualification) with each \"git add\" action AND are noted in the Index at\n> the same time. Therefore the Index is quite literally containing\n> information about the blobs to be committed without containing the blobs\n> themselves. This is why I find any specific equivalence between Index\n> and \"staging area\" distasteful--it is misleading.\n\nThere's no reason to make it more confusing by telling all the\nimplementation details users are not interested in.\n\nOnce I add a modified file to index (via 'git add') or even add a new\nfile, its content is already tracked by git. This is the most relevant\npart.\n\nIt is not relevant from the user's point of view whether it's already\nin .git/objects or not. Once I've staged a file, I can rm it and then\n'git checkout' it again to the version that's remembered in the\nstaging area, i.e. I will not lose it's contents once it's been\nstaged.\n\nIf what you're trying to say is that new users think of the 'staging\narea' as some place where the content is stored before a subsequent\ncommit, there's nothing bad about it. If they will try to find out\nabout it's concrete location in the fs, they'll eventually find out\nabout index and its true nature in terms of implementation.\n\n--\nBest regards,\nAlexei Sholik\n"},{"id":"162561","messageId":"1299001318.5247.57.camel@drew-northup.unet.maine.edu","threadId":"26489","inReplyTo":"AANLkTikCEoc55WuiRNo6Q=sXqTd_WDfVRb6cnN5bRD=0@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2011-03-01T17:41:58Z","receivedAt":"2011-03-01T17:41:58Z","isPatch":false,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Tue, 2011-03-01 at 19:30 +0200, Alexei Sholik wrote:\n> On 1 March 2011 19:02, Drew Northup wrote:\n> >\n> > On Tue, 2011-03-01 at 11:32 +0200, Alexei Sholik wrote:\n> >\n> >> I guess, people who are friendly with git using the word \"index\"\n> >> because it's easier to type. But it confuses an unprepared reader. The\n> >> solution of the problem with confusion must be relevant to these\n> >> points:\n> >> - clarify that \"index\" means the same thing as the \"staging area\" (in\n> >> man if it isn't there already?)\n> >\n> > Alas, this isn't quite true. Blobs are copied to the .git/objects\n> > directory (which I referred to earlier as an object store without proper\n> > qualification) with each \"git add\" action AND are noted in the Index at\n> > the same time. Therefore the Index is quite literally containing\n> > information about the blobs to be committed without containing the blobs\n> > themselves. This is why I find any specific equivalence between Index\n> > and \"staging area\" distasteful--it is misleading.\n> \n> There's no reason to make it more confusing by telling all the\n> implementation details users are not interested in.\n\nI am not advocating that.\n\n> Once I add a modified file to index (via 'git add') or even add a new\n> file, its content is already tracked by git. This is the most relevant\n> part.\n\nAgreed.\n\n> It is not relevant from the user's point of view whether it's already\n> in .git/objects or not. Once I've staged a file, I can rm it and then\n> 'git checkout' it again to the version that's remembered in the\n> staging area, i.e. I will not lose it's contents once it's been\n> staged.\n> \n> If what you're trying to say is that new users think of the 'staging\n> area' as some place where the content is stored before a subsequent\n> commit, there's nothing bad about it. If they will try to find out\n> about it's concrete location in the fs, they'll eventually find out\n> about index and its true nature in terms of implementation.\n\nMy argument is that we should use \"staging area\" or \"preparation area\"\nor whatever we end up using as tools to explain the USAGE of Git without\ninferring that IT WORKS THAT WAY DEEP INSIDE. That's why I don't want to\nclaim that the Index is (or means the same thing as) a staging area--we\nshouldn't be bothering beginner users with the Index yet anyway. Just\nsaying that the information gets put into files in .git that act as a\n\"staging area\" is good enough--we don't need to extricate all mentions\nof \"Index\" or \"cache\" from the documentation.\nUnfortunately, if this is not done carefully we end up with people\ncomplaining that the documentation is inconsistent when it is often just\nblunt and indelicately worded.\n\n-- \n-Drew Northup\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"162776","messageId":"AANLkTinAUsY-d3Ec6HpKbjzC+eUjGcq1LK5ODjxRC-yz@mail.gmail.com","threadId":"26489","inReplyTo":"1298997963.5247.30.camel@drew-northup.unet.maine.edu","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-03-04T17:18:51Z","receivedAt":"2011-03-04T17:18:51Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Mar 1, 2011 at 6:46 PM, Drew Northup wrote:\n>\n> On Tue, 2011-03-01 at 10:27 +0100, Alexey Feldgendler wrote:\n>> On Tue, 01 Mar 2011 10:11:11 +0100, David wrote:\n>>\n>> > A suggestion: could your conceptual bucket be named as \"the precommit\".\n>> >\n>> > Motives for this suggestion are:\n>> > 1)  I imagine this word will be readily translatable;\n>>\n>> Less so than “staging area”, at least into Russian.\n>>\n>> Just my two cents.\n>\n> I was starting to think about \"commit preparation area\" this morning,\n> but it sounds horribly long. Would \"Prep area\" work provided that the\n> longer version has already been introduced into the discussion? This\n> provides a similar language metaphor to \"staging area\" hopefully without\n> the translation problem.\n>\n> Also, I still think that it is important to note somewhere that the way\n> that git handles commits is not the way that most users are likely to\n> imagine (the Index doesn't contain the blob objects itself; a finalized\n> commit is not just a bundled collection of everything as somebody might\n> expect; etc) so this \"Prep area\" is a logical space not completely\n> analogous to stuff found in the \".git\" directory. Pretending that\n> complexity does not exist will not help; letting the users know that\n> they don't need to grok all of the details to get started is, on the\n> other hand, quite important.\n\nFirst I liked this proposal, but then I thought about 'git diff\n--preped' (doesn't really sound right). I think the term should:\n\n 1) Have a nice noun version; staging area, preparation area\n 2) Have a nice verb version; to stage, to prep\n 3) Have a nice past-participle; staged, cached\n\nCasting? Forging? I don't know, staging always seems right.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"162805","messageId":"AANLkTimX3n5PNdK9YpA92SQM7G-WAiC1aPP7qJ-UEudq@mail.gmail.com","threadId":"26489","inReplyTo":"AANLkTinAUsY-d3Ec6HpKbjzC+eUjGcq1LK5ODjxRC-yz@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2011-03-05T04:53:21Z","receivedAt":"2011-03-05T04:53:21Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"2011/3/5 Felipe Contreras :\n> First I liked this proposal, but then I thought about 'git diff\n> --preped' (doesn't really sound right). I think the term should:\n>\n>  1) Have a nice noun version; staging area, preparation area\n>  2) Have a nice verb version; to stage, to prep\n>  3) Have a nice past-participle; staged, cached\n>\n> Casting? Forging? I don't know, staging always seems right.\n\nI agree.\n\nI don't why so many people seem to be trying so hard to come with\nalternatives to \"staged\" and \"staging area\", when the latter are\nactually quite good; so far all the suggestions have been much more\nawkward and less intuitive.\n\nIt's true that \"staging area\" and \"stage\" as a verb are most intuitive\nfor native english speakers, but so far none of the alternatives\nreally seem any better for non-native speakers. _All_ of these terms\nare \"learned\" to some degree, and in that sense are arbitrary, but the\nsmoothness and intuitiveness of \"staging area\"/\"stage\" for english\nspeakers is a real plus I think.\n\nAs for translations, is it even an issue? If term \"XXX\" is the\noptimum term in some other language, then that should be the\ntranslation for that langage, _regardless_ of what the english term\nused is.\n\n-miles\n\n-- \nCat is power.  Cat is peace.\n"},{"id":"162806","messageId":"20110305050030.GC22976@elie","threadId":"26489","inReplyTo":"AANLkTimX3n5PNdK9YpA92SQM7G-WAiC1aPP7qJ-UEudq@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-03-05T05:00:30Z","receivedAt":"2011-03-05T05:00:30Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Miles Bader wrote:\n\n> I don't why so many people seem to be trying so hard to come with\n> alternatives to \"staged\" and \"staging area\", when the latter are\n> actually quite good; so far all the suggestions have been much more\n> awkward and less intuitive.\n\n*nod* Actually, \"staging area\" is intuitive on first reading and\n\"stage\" less so to me, while the alternatives tend to be more\nconfusing for what it's worth.\n\nI think this thread has outlived its usefulness. Could people with\nconcrete proposals (e.g., \"the description of 'git add' is confusing\nin such-and-such way; this rewording makes it clearer\", or \"the\nglossary does not describe the staging area very well; how about\nthis description\") please start new threads?\n\nThanks,\nJonathan\n"},{"id":"162844","messageId":"1299415483.5468.18.camel@drew-northup.unet.maine.edu","threadId":"26489","inReplyTo":"AANLkTimX3n5PNdK9YpA92SQM7G-WAiC1aPP7qJ-UEudq@mail.gmail.com","subject":"Re: Consistent terminology: cached/staged/index","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2011-03-06T12:44:43Z","receivedAt":"2011-03-06T12:44:43Z","isPatch":false,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Sat, 2011-03-05 at 13:53 +0900, Miles Bader wrote:\n> 2011/3/5 Felipe Contreras :\n> > First I liked this proposal, but then I thought about 'git diff\n> > --preped' (doesn't really sound right). I think the term should:\n> >\n> > 1) Have a nice noun version; staging area, preparation area\n> > 2) Have a nice verb version; to stage, to prep\n> > 3) Have a nice past-participle; staged, cached\n> >\n> > Casting? Forging? I don't know, staging always seems right.\n> \n> I agree.\n> \n> I don't why so many people seem to be trying so hard to come with\n> alternatives to \"staged\" and \"staging area\", when the latter are\n> actually quite good; so far all the suggestions have been much more\n> awkward and less intuitive.\n> \n> It's true that \"staging area\" and \"stage\" as a verb are most intuitive\n> for native english speakers, but so far none of the alternatives\n> really seem any better for non-native speakers. _All_ of these terms\n> are \"learned\" to some degree, and in that sense are arbitrary, but the\n> smoothness and intuitiveness of \"staging area\"/\"stage\" for english\n> speakers is a real plus I think.\n\nIt has already been pointed out that this isn't always quite as\nintuitive as it sounds to many. I think we'd be flogging a dead horse to\ncontinue discussing that.\n\n> As for translations, is it even an issue? If term \"XXX\" is the\n> optimum term in some other language, then that should be the\n> translation for that langage, _regardless_ of what the english term\n> used is.\n> \n> -miles\n\nHaving translated stuff before, and having helped clean-up / finish\ntranslations from other languages to English, I can say that it most\ncertainly DOES MATTER what the idiom used in the source language is.\nUnless I the translator know more about how something works than the\ncore developers that wrote it I am highly dependent on the explanations\nthey have used. That is why it is important to have a complete and\nportable metaphor. In fact, that's exactly what I was thinking about\nwhen I suggested \"commit preparation area\" earlier in this thread--the\ntranslation to Spanish is a tad verbose but it is entirely clear without\nfurther jiggering or expectation of specific cultural knowledge. \n\nI'm not sure why that \"fails\" the equally arbitrary participle-mapping\ntest... It sure has one, but as a native English speaker and a brutal\neditor I am perfectly comfortable with the notion that not all verbs\nhave natural noun forms and vice-versa.\n\n-- \n-Drew Northup\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"}]}