Re: Officially start moving to the term 'staging area'
Drew Northup <n1xim.email@gmail.com> napisał:
Show 7 quoted lines
>I agree with Junio. This effort is better spent making the
>documentation clearer and more succinct. The reality is that a user
>needs to build a model in their mind of what they are doing which maps
>enough (completely is not required) to what is actually going on to
>get work done. If the documentation or the instruction is getting in
>the way of that in the name of simplifying the presentation then the
>presentation is wrong.
Why do you think the "stage" model do not map enough?
Show 8 quoted lines
>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.
The above can be rewritten to use the 'staging area' concept just fine. And I don't think you should say to inexperienced users things like 'tree objects'.
A good exercise would be to take documentation of some command and show that it can or can't be rewritten to use the other term.
Instead of 'indexing' or 'staging' content you could also use term 'mark'. You mark content to add, for removal, you can diff it or revert.
>
>That's the real model (with some rough edges). Explaining what that
>has to do with distributed version control is the hard part.
--
Piotr Krukowiecki
Piotr Krukowiecki <piotr.krukowiecki@gmail.com>