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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Sep 8, 2013, 09:27 UTC
Message-ID: <CAMP44s2ANuLL_gPrn8Od3nwQimd+JQASW4wF-xVJRF0eA+WkRA@mail.gmail.com>
In-Reply-To: <B771340AAC04409CB0EF716FE6FC1C88@PhilipOakley>

On Sun, Sep 8, 2013 at 2:49 AM, Philip Oakley <philipoakley@iee.org> wrote:

Show 14 quoted lines

> 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.

Not really. You can argue that a movie is a sequence of snapshots, 24 of them per second, but most people don't think of it that way. You can also argue that every change you do on a file is a snapshot, but again, people don't think of it that way. Yes, you can argue that the index is a snapshot, but it doesn't help to think of it that way. And if you try to argue that way, then every waking moment is a snapshot, what is NOT a snapshot?

The useful concept of snapshot is a moment in time stored for posterity, in that sense a photo is a snapshot, a backup is a snapshot, and a commit is a snapshot, but the staging area is not, because it will be gone.

In fact, I just thought of another concept; a draft.

Show 7 quoted lines

> 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 ;-)

But that doesn't work well. You didn't add and remove things for the 'For Filing' as you worked, did you? Even if it did work, I don't think it would be particularly useful to most people today.

I think a much more fitting analogy is a mail draft; you add and remove things, change them, review, you can take as much time as you want, and at the end of the day you can discard the whole thing. Nothing gets done until you press 'send', which is analogous to 'commit'.

Show 11 quoted lines

>> _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.

I still don't see it. When you do 'git commit' you don't have an array of snapshots to choose from, you just have one, and it's not particularly static, as you can add and remove things from it, so it's not really a snapshot of your working directory even, because you can add things that where never there.

And then if the staging area is a snapshot, then what is a commit? Another snapshot? Then what is the difference between the two? One is permanent and the other temporary? Well, then saying "snapshot" wouldn't be enough to describe the staging area, you would need to say "preliminary snapshot", which doesn't really make sense, as those are called previews, not snapshots. But why bother with "snapshot", we can use "preliminary commit". But again, it sounds weird using the word commit to something that can and is meant to change, unlike git commits, and incidentally, unlike snapshots.

-- 
Felipe Contreras