Re: Consistent terminology: cached/staged/index
- From
Felipe Contreras <felipe.contreras@gmail.com>
- Date
- Feb 26, 2011, 21:09 UTC
- Message-ID
- <AANLkTik-jc0ZX9S4bCYV8VBgPXJZsX0U08W2H+jufO8r@mail.gmail.com>
- In-Reply-To
- <20110214231920.GA24814@elie>
On Tue, Feb 15, 2011 at 1:19 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> When people talk about the staging area I tend to get confused. I > think there's an idea that because it sounds more concrete, there is > less to explain --- or maybe I am just wired the wrong way.
I don't like the phrase "staging area". A "stage" already has an area. You put things on the stage. Sometimes there are multiple stages.
Show 5 quoted lines
> There is a .git/index file, with a well defined file format. And > there is an in-core copy of the index, too. It contains: > > - mode and blob name for paths as requested by the user with > "git add"
A commit stage.
> - competing versions for paths whose proposed content is > uncertain during a merge
Multiple commit stages.
> - stat(2) information to speed up comparison with the worktree
If only a subset of the files are there, it's an 'index', if not, then I'd say it's a 'registry'. Anyway, it's something the user shouldn't care about.
Cheers.
-- Felipe Contreras