Re: Consistent terminology: cached/staged/index

[Alexei Sholik <alcosholik@gmail.com>]

On 1 March 2011 19:02, Drew Northup <drew.northup@maine.edu> wrote:
>
> On Tue, 2011-03-01 at 11:32 +0200, Alexei Sholik wrote:
>
>> I guess, people who are friendly with git using the word "index"
>> because it's easier to type. But it confuses an unprepared reader. The
>> solution of the problem with confusion must be relevant to these
>> points:
>>  - clarify that "index" means the same thing as the "staging area" (in
>> man if it isn't there already?)
>
> Alas, this isn't quite true. Blobs are copied to the .git/objects
> directory (which I referred to earlier as an object store without proper
> qualification) with each "git add" action AND are noted in the Index at
> the same time. Therefore the Index is quite literally containing
> information about the blobs to be committed without containing the blobs
> themselves. This is why I find any specific equivalence between Index
> and "staging area" distasteful--it is misleading.

There's no reason to make it more confusing by telling all the
implementation details users are not interested in.

Once I add a modified file to index (via 'git add') or even add a new
file, its content is already tracked by git. This is the most relevant
part.

It is not relevant from the user's point of view whether it's already
in .git/objects or not. Once I've staged a file, I can rm it and then
'git checkout' it again to the version that's remembered in the
staging area, i.e. I will not lose it's contents once it's been
staged.

If what you're trying to say is that new users think of the 'staging
area' as some place where the content is stored before a subsequent
commit, there's nothing bad about it. If they will try to find out
about it's concrete location in the fs, they'll eventually find out
about index and its true nature in terms of implementation.

--
Best regards,
Alexei Sholik