On Tue, Sep 3, 2013 at 11:45 PM, Drew Northup <n1xim.email@xxxxxxxxx> wrote: > On Thu, Aug 29, 2013 at 6:10 PM, Felipe Contreras > <felipe.contreras@xxxxxxxxx> wrote: >> On Thu, Aug 29, 2013 at 4:55 PM, Drew Northup <n1xim.email@xxxxxxxxx> wrote: >>> On Thu, Aug 29, 2013 at 2:37 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>>> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: >>>> >>>>> It has been discussed many times in the past that 'index' is not an >>>>> appropriate description for what the high-level user does with it, and >>>>> it has been agreed that 'staging area' is the best term. >>>> >>>> "add" is the verb, not "index" (which is a noun that refers >>>> to the thing that keeps track of what will be written as a tree to >>>> be committed next). >>>> >>>> And it will stay that way. > >>> I agree with Junio. >> >> All right, you are the only person (presumably other than Junio) that >> thinks "index" is the right name for what high-level users should be >> familiar with. > > If that were true it would never have gotten that name. This is fallacious on so many levels. First, there's the concept of legacy; what the developers of today think, is different than what the developers of the past did, there might be more, there might be less, there might be different people, or they might have changed their mind, so what old developers thought doesn't reflect what the developers today think. Second, there's this thing called "idea", and nobody is born with all the ideas in the world and history; ideas present themselves, and if nobody chose the new term, it might have been because they simply didn't think about it. Third, they might have not thought enough about the name in the first place, they thought "index" was good enough, and could be fixed later if need be. Fourth, only the developers were involved in picking the name, not users, so what the vast majority of users thought didn't factor into the name. So yeah, you are totally wrong. > "Add" is the verb, as we are adding a snapshot. Add a snapshot to where? To the repository? To a temporary stash? To an online location. The concept of "adding a snapshot" is meaningless. > New users don't care how that works > for the most part. Just telling them "it keeps track of it itself" is > usually good enough. Everything in a computer "keeps track of it itself", that's what a Von Neumann computer does, because it has memory. When you type a character it's kept in track, when you save a file it's kept in track. Knowing that something "is kept in track" is not useful at all. > If the user is asking for more detail at that > point it is probably because he isn't as much interested in how to use > it as he is in how it works. Wrong. The user might be interested in knowing what the hell you are talking about. Adding what to what, and for what purpose. > At that point we're better off just > giving him the actual explanation instead of getting caught up in the > staging area vs index fight (which seems odd to me as the index > contains the entries which act as a "staging area"--a superset / > subset relation). Wrong. An index has absolutely nothing to do with a staging area. I already explained multiple times the difference; an index is information used to quickly find things, a staging area is used to put things in preparation of something. Even we are to use the index, the user needs to know what is being indexed to what, for example, in a book index, words are being indexed to their page numbers. It turns out we can't do that, because technically Git does not have an index, but rather a manifest, or a registry, or more generally, working tree metadata. But that is not relevant, because we don't need to explain what each every field in .git/index is, and it's binary format is, all we need to do is explain what it's used for; it's used to prepare the contents of the next commit, in other words; it's used as a staging area. So when you "add to the staging area" you know what you add, to what, and for what purpose. >>> We add content snapshots to the index of content (creating >>> "temporary"--they will be garbage collected eventually if they become >>> orphans--objects into the store at the same time). We build commits >>> from those snapshots (in whole or in part, typically only using the >>> most recent snapshots of new things added to the index) and save those >>> in the object store with the content and tree objects. Sometimes we >>> create tag objects to record something special about commits, trees, >>> and content blobs. >>> >>> That's the real model (with some rough edges). Explaining what that >>> has to do with distributed version control is the hard part. >> >> The user doesn't need to know the format of the index, or the packs, >> in fact, they don't even need to know the index or packs even exist. > > I never implied that the end user does need to know these things. > (Note the use of "We"--as in "we who are having this conversation.") We who are having this conversation are irrelevant. Stop with the red herrings. We are talking about the vast majority of users and what's best for *them*. >> All the user needs to know about this is that there's an area where >> contents of the next commit are being prepared, and "staging area" is >> the best name for that mental area. How that area is actually >> implemented (the index) is not relevant to the user. > > Part of what I am arguing is that the mental area doesn't need to > exist at all. The "staging area" is a part of the index. Again, the term "index" and the term "staging area" in the English language have absolutely nothing to do one with the other. >> Everyone agrees on that, except you, and possibly Junio. > > We don't have enough information to say that. Seriously, this is > nowhere near as certain as climate change. Show me a single person except you and Junio that doesn't like the term "staging area". Until you do, the claim remains; virtually everyone agrees. -- Felipe Contreras -- 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