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 index. 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'. Andreas -- "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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html