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

Re: Consistent terminology: cached/staged/index

From
VEVictor Engmark <victor.engmark@terreactive.ch>
Date
Mar 1, 2011, 08:43 UTC
Message-ID
<4D6CB1B3.1010005@terreactive.ch>
In-Reply-To
<878466.93199.1298934204331.JavaMail.trustmail@mail1.terreactive.ch>
On 03/01/2011 12:03 AM, Jeff King wrote:
> On Sun, Feb 27, 2011 at 10:34:00AM -0500, Drew Northup wrote:
Show 25 quoted lines
> One analogy I like for the index is that it's a bucket. It starts out
> full of files from the last commit. You can put new, changed files in
> the bucket. When it looks good, you dump the bucket into a commit. You
> can have multiple buckets if you want. You can pull files from other
> commits and put them in the bucket. You can take files out of the bucket
> and put them in your work tree.
> 
> So maybe it should just be called "the bucket"?
> 
> I'm not sure that's a good idea, because while the analogy makes sense,
> it doesn't by itself convey any meaning. That is, knowing the concept, I
> can see that bucket is a fine term. But hearing about git's bucket, I
> have no clue what it means. Whereas "staging area" I think is a bit more
> specific, _if_ you know what a staging area is.
> 
> So there are two questions:
> 
>   1. Is there a more universal term that means something like "staging
>      area"?
> 
>   2. Is the term "staging area", while meaningful to some, actually
>      _worse_ to others than a term like "bucket"? That is, does it sound
>      complex and scary, when it is really a simple thing. And while
>      people won't know what the "git bucket" is off the bat, it is
>      relatively easy to learn.
I like the name "git bucket", as in "a git bit bucket", but semantically
the connection is just "a container". Especially for beginners this can
result in the wrong connotations:
* Limited size. A modern harddisk is vastly larger than most Git
repositories, likening it more to a container ship than a bucket.
* Definite size. Harddisk space availability varies with time, unlike
most containers.
* Non-linear use. A full physical bucket could be used for many
different things, but a full git bucket can either be forgotten (with
checkout), remembered temporarily (with stash), or remembered
permanently (with commit).
* Container-specific features irrelevant for git: Handles, translucency
(or not), depth, material, dimensions of the opening...

How about a metaphor like "plan"? You either cancel/undo it (git checkout), postpone / shelf it (git stash), resume/continue it (git stash apply) or commit to it. Coming from the desktop metaphor, I personally like `git undo`, `git postpone/resume` and `git commit` - They give a clear sense of direction towards the commit, and much clearer verbs for those new to VC in general.

-- 
Victor Engmark
Previous: Jonathan Nieder
Message 65 of 65 in “Consistent terminology: cached/staged/index”
  1. Piotr KrukowieckiFeb 13, 2011
  2. Jonathan NiederFeb 13, 2011
  3. Junio C HamanoFeb 13, 2011
  4. Miles BaderFeb 14, 2011
  5. Junio C HamanoFeb 14, 2011
  6. Miles BaderFeb 14, 2011
  7. Johannes SixtFeb 14, 2011
  8. Miles BaderFeb 14, 2011
  9. Michael J GruberFeb 14, 2011
  10. Miles BaderFeb 14, 2011
  11. Junio C HamanoFeb 14, 2011
  12. Miles BaderFeb 14, 2011
  13. Junio C HamanoFeb 14, 2011
  14. Miles BaderFeb 14, 2011
  15. Junio C HamanoFeb 15, 2011
  16. Nguyen Thai Ngoc DuyFeb 14, 2011
  17. Michael J GruberFeb 14, 2011
  18. Nguyen Thai Ngoc DuyFeb 14, 2011
  19. Felipe ContrerasFeb 14, 2011
  20. Nguyen Thai Ngoc DuyFeb 14, 2011
  21. Jakub NarebskiFeb 14, 2011
  22. Michael J GruberFeb 14, 2011
  23. Felipe ContrerasFeb 14, 2011
  24. Michael J GruberFeb 14, 2011
  25. Felipe ContrerasFeb 14, 2011
  26. Pete HarlanFeb 14, 2011
  27. Drew NorthupFeb 16, 2011
  28. Felipe ContrerasFeb 26, 2011
  29. Drew NorthupFeb 27, 2011
  30. AghilesFeb 27, 2011
  31. Drew NorthupFeb 28, 2011
  32. Piotr KrukowieckiFeb 14, 2011
  33. Jonathan NiederFeb 14, 2011
  34. Pete HarlanFeb 15, 2011
  35. Jonathan NiederFeb 15, 2011
  36. Piotr KrukowieckiFeb 15, 2011
  37. Jonathan NiederFeb 15, 2011
  38. Felipe ContrerasFeb 26, 2011
  39. Jonathan NiederFeb 26, 2011
  40. Miles BaderFeb 27, 2011
  41. Felipe ContrerasFeb 27, 2011
  42. Jonathan NiederFeb 27, 2011
  43. Junio C HamanoFeb 27, 2011
  44. Jeff KingFeb 27, 2011
  45. Miles BaderFeb 27, 2011
  46. Jon SeymourFeb 27, 2011
  47. Junio C HamanoFeb 27, 2011
  48. Michael J GruberFeb 28, 2011
  49. Drew NorthupFeb 27, 2011
  50. Jeff KingFeb 28, 2011
  51. DavidMar 1, 2011
  52. Matthieu MoyMar 1, 2011
  53. Alexei SholikMar 1, 2011
  54. Drew NorthupMar 1, 2011
  55. Alexei SholikMar 1, 2011
  56. Drew NorthupMar 1, 2011
  57. Alexey FeldgendlerMar 1, 2011
  58. Drew NorthupMar 1, 2011
  59. Felipe ContrerasMar 4, 2011
  60. Miles BaderMar 5, 2011
  61. Jonathan NiederMar 5, 2011
  62. Drew NorthupMar 6, 2011
  63. Phil HordFeb 27, 2011
  64. Jonathan NiederMar 1, 2011
  65. Victor EngmarkMar 1, 2011

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.