git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Officially start moving to the term 'staging area'

From
Felipe Contreras <felipe.contreras@gmail.com>
Date
Aug 29, 2013, 18:01 UTC
Message-ID
<20130829180129.GA4880@nysa>
Hi,

It has been discussed many times in the past that 'index' is not an appropriate description for what the high-level user does with it, and it has been agreed that 'staging area' is the best term.

The term 'staging area' is more intuitive for newcomers which are more familiar with English than with Git, and it seems to be a straightforward mental notion for people with different mother tongues.

In fact it is so intuitive that it's used already in a lot online documentation, and the people that do teach Git professionally use this term, because it's easier for many kinds of audiences to grasp.

The meaning of the words 'cache' and 'index' doesn't represent correctly the mental model of the high-level user:

cache: a 'cache' is a place for easier access; a squirrel caches nuts so it doesn't have to go looking for them in the future when it might be much more difficult. Git porcelain is not using the staging area for easier future access; it's not a cache.

index: an 'index' is a guide of pointers to something else; a book index has a list of entries so the reader can locate information easily without having to go through the whole book. Git porcelain is not using the staging area to find out entries quicker; it's not an index.

stage: a 'stage' is a special area designated for convenience in order for some activity to take place; an orator would prepare a stage in order for her speak to be successful, otherwise many people might not be able to hear, or see her. Git porcelain is using the staging area precisely as a special area to be separated from the working directory for convenience.

The term 'stage' is a good noun itself, but also 'staging area', it has a good verb; 'to stage', and a nice past-participle; 'staged'.

The first step in moving Git towards this term, is first to add --stage options for every command that uses --index or --cache. However, there's a problem with the 'git apply' command, because it treats --index and --cache differently. Different solutions were proposed, including a special --stage-only option, however, I think the best solution is a --[no-]work option to specify if the working directory should be touched or not, so --index becomes --staged, and --cached becomes --staged --no-work.

In addition, the 'git stage' command can be extended so the staging area can be brought closer to the user, like other important Git concepts, like 'git branch, 'git tag', and 'git remote'. For example, the command 'git stage edit' (which allows the user to edit directly the diff from HEAD to the staging area) can have a home, where previously there was no place. It would become natural then to do 'git stage diff', and then 'git stage edit' (to edit the previous diff).

After adding the new --stage options and making sure no functionality is lost, they can become the recommended ones in the documentation, eventually, the old ones get deprecated, and eventually obsoleted.

Also, the documentation would need to be updated to replace many instances of 'the index', with 'the staging area' in porcelain commands.

Moreover, the --stage and --work options also make sense for 'git reset', and after these options are added, the complicated table to explain the different behaviors between --soft, --mixed, and --hard becomes so simple it's not needed any more:

      working stage HEAD target             working stage HEAD
      ----------------------------------------------------
       A       B     C    D     --no-stage  A       B     D
				--stage     A       D     D
				--work      D       D     D
      working stage HEAD target             working stage HEAD
      ----------------------------------------------------
       A       B     C    C     --no-stage  A       B     C
				--stage     A       C     C
				--work      C       C     C
      working stage HEAD target             working stage HEAD
      ----------------------------------------------------
       B       B     C    D     --no-stage  B       B     D
				--stage     B       D     D
				--work      D       D     D
      working stage HEAD target             working stage HEAD
      ----------------------------------------------------
       B       B     C    C     --no-stage  B       B     C
				--stage     B       C     C
				--work      C       C     C
      working stage HEAD target             working stage HEAD
      ----------------------------------------------------
       B       C     C    D     --no-stage  B       C     D
				--stage     B       D     D
				--work      D       D     D
      working stage HEAD target             working stage HEAD
      ----------------------------------------------------
       B       C     C    C     --no-stage  B       C     C
				--stage     B       C     C
				--work      C       C     C

It might be possible to do 'git reset --no-stage --work', to reset the working directory, but leave the staging area alone.

For more reference about the previous discussions:

http://thread.gmane.org/gmane.comp.version-control.git/197111 http://thread.gmane.org/gmane.comp.version-control.git/166675 http://thread.gmane.org/gmane.comp.version-control.git/115666

-- 
Felipe Contreras
Next: Felipe Contreras
Message 1 of 58 in “Officially start moving to the term 'staging area'”
  1. Felipe ContrerasAug 29, 2013
  2. 0/2 stage: proper 'stage' commandFelipe Contreras, Aug 29, 2013
  3. 1/2 Add proper 'stage' commandFelipe Contreras, Aug 29, 2013
  4. Matthieu MoyAug 29, 2013
  5. Felipe ContrerasAug 29, 2013
  6. 2/2 stage: add edit commandFelipe Contreras, Aug 29, 2013
  7. Matthieu MoyAug 29, 2013
  8. Felipe ContrerasAug 29, 2013
  9. 0/9 Add --stage and --work optionsFelipe Contreras, Aug 29, 2013
  10. 1/9 diff: document --stagedFelipe Contreras, Aug 29, 2013
  11. 2/9 grep: add --staged optionFelipe Contreras, Aug 29, 2013
  12. 3/9 rm: add --staged optionFelipe Contreras, Aug 29, 2013
  13. 4/9 stash: add --stage option to saveFelipe Contreras, Aug 29, 2013
  14. Matthieu MoyAug 29, 2013
  15. 5/9 stash: add --stage to pop and applyFelipe Contreras, Aug 29, 2013
  16. 6/9 submodule: add --staged optionsFelipe Contreras, Aug 29, 2013
  17. 7/9 apply: add --stage optionFelipe Contreras, Aug 29, 2013
  18. 8/9 apply: add --work, --no-work optionsFelipe Contreras, Aug 29, 2013
  19. 9/9 completion: update --staged optionsFelipe Contreras, Aug 29, 2013
  20. 0/3 reset: refactor into --stage and --workFelipe Contreras, Aug 29, 2013
  21. 1/3 reset: add --stage and --work optionsFelipe Contreras, Aug 29, 2013
  22. 2/3 reset: allow --keep with --stageFelipe Contreras, Aug 29, 2013
  23. 3/3 completion: update 'git reset' new stage optionsFelipe Contreras, Aug 29, 2013
  24. Junio C HamanoAug 29, 2013
  25. Felipe ContrerasAug 29, 2013
  26. Felipe ContrerasAug 30, 2013
  27. Felipe ContrerasAug 30, 2013
  28. Felipe ContrerasAug 30, 2013
  29. Felipe ContrerasAug 30, 2013
  30. Drew NorthupAug 29, 2013
  31. Felipe ContrerasAug 29, 2013
  32. Drew NorthupSep 4, 2013
  33. Felipe ContrerasSep 8, 2013
  34. Piotr KrukowieckiAug 30, 2013
  35. Drew NorthupSep 4, 2013
  36. Piotr KrukowieckiSep 4, 2013
  37. Drew NorthupSep 4, 2013
  38. Felipe ContrerasSep 8, 2013
  39. Felipe ContrerasSep 8, 2013
  40. Felipe ContrerasSep 8, 2013
  41. Philip OakleySep 8, 2013
  42. Felipe ContrerasSep 8, 2013
  43. Matthieu MoyAug 29, 2013
  44. Felipe ContrerasAug 29, 2013
  45. Matthieu MoyAug 29, 2013
  46. Matthieu MoyAug 29, 2013
  47. René ScharfeAug 29, 2013
  48. Felipe ContrerasAug 29, 2013
  49. René ScharfeAug 31, 2013
  50. Felipe ContrerasAug 31, 2013
  51. David AguilarSep 1, 2013
  52. Matthieu MoyAug 29, 2013
  53. William SwansonSep 4, 2013
  54. Ping YinSep 6, 2013
  55. Hilco WijbengaSep 6, 2013
  56. Felipe ContrerasSep 8, 2013
  57. Ramkumar RamachandraSep 9, 2013
  58. Felipe ContrerasSep 9, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.