On Thu, 24 Oct 2013 02:57:15 +0000, Karsten Blees wrote:
> The latter. I don't know about 'broader', but I'll try to summarize _my_
> world view:
> (1) Audience matters
> For actual users, we need an accurate model that supports a variety of use
> cases without falling apart. IMO, a working model is more important than
> simplicity. Finally, its more important to agree on the actual model than on
> a vague term that can mean many things (theater stage vs. loading dock...).
Terms almost invariable mean multiple things in different contexts,
and assume new meaning in new fields.
> For potential users / decision makers, we need to describe git's features in
> unmistakable terms that don't need extra explanation. In this sense, the
> index / cache / staging area is not a feature in itself but facilitates a
> variaty of broader features:
> - fine grained commit control (via index (add -i), but also commit -p, commit
> --amend, cherry-pick, rebase etc.)
The audience will have a hard time understanding what these features
actually do (and how they interact) if we hide the underlying model from
them - they then need to build that model themselves.
And no decision-maker will make the effort to understand either the
operations you mention or the concept of the staging area, unless they
are also users.
> An index, as in a library, maps almost perfectly to what the git index is
> _and_ what we do with it.
No, it doesn't. The git index actually contains the content of the added
files, not just an identity reference. (Unless, maybe, you consider file
sha1s as a reference and not actual content.) The point is that the
index doesn't just contain a mapping from file names to some objects,
but de facto a tree - that will form the next commit.
> (3a) Staging area (logistics)
> A staging area, as in (military) logistics / transportation, is about moving
> physical goods around. You move an item from your stock to the staging area,
> then onto the truck and finally deliver it to the customer.
> The defining characteristic of a physical good is its physical existence.
> Each item is uniquely identifiable by a serial number.
Please show me the serial numbers on bullets.
> Problem #1: If an item in the staging area is broken, you fix it directly in
> the staging area, because that's where it _is_.
That may be true in a physical world, and may not be - you can as well
replace them instead of repairing them in place.
The real problem: You can find some reason why any possible existing
name for this concept isn't correct.
> I don't see how a stage (as in a theater) is in any way related to the git
It's because the name 'stage (noun)' goes with the verb 'stage'. You
stage a play, or you stage content to be committed. From that, you
may almost call the index just 'stage'.
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html