Re: Officially start moving to the term 'staging area'

["Philip Oakley" <philipoakley@iee.org>]

From: "Felipe Contreras" <felipe.contreras@gmail.com>
Sent: Sunday, September 08, 2013 2:33 AM
[snip...]
> The snapshot concept is totally orthogonal from the staging area
> concept. Git works in snapshots, which are frozen images of how the
> content tree was at a certain point in time; IOW; a commit.

(I feel that) In most peoples minds the need for a staging area, and the 
use of snapshots, are related. Part of that relationship, often not 
noticed by those folks, is that they are 'orthogonal' to *each other*. 
Thus orthogonality means both un-related, and related at the same time 
(aren't we humans peculiar!). They are cleaved to each other.

When trying to explain staging/index I tend to use the analogy of an old 
style office (I am almost that old) where one has an In tray and an Out 
tray on one's desk (and one parked WIP for lunch time desk tidy), and 
the staging area is the basket at the end marked 'For Filing'. When the 
'For Filing' basket is ready, one called the filing clerk to dictate the 
cover note and away it went, commited to some remote filing repository. 
Oh how things have changed ;-)

>
> _How_ that snapshot is created is an entirely different topic, and the
> staging area is a tool to create the desired snapshots. The user might
> decide to never use that tool (i.e. always run git commit -a), but the
> concept of snapshots remain. So, clearly, one concept has absolutely
> nothing to do with the other.
>

The point would be that we allow a particular snapshot to be selected, 
and that the git commit -a is but one (common) method. Commit -a is like 
jumping in the car for a quick trip to the shops, while the selective 
staging of content is like packing for a holiday.