Re: Hey - A Conceptual Simplication....

[Jakub Narebski <jnareb@gmail.com>]

On Thu, 19 Nov 2009, George Dennie wrote:

> Thanks Jakub Narebski and Björn Steinbrink...Nice description Björn.
> 
> I think an important piece of conceptual information missing from the docs
> is a concise list of the conceptual properties defining the context of the
> working tree, index, and repository during normal use. This itemization
> would go far in explaining the synergies between the various commands.

If you didn't find sufficient description of underlying concepts behind
git in "Git User's Manual" (distributed with Git), "Git Community Book"
or "Pro Git", take a look at the following documents:

 * "Git for Computer Scientists"
 * "Git From Bottom's Up"
 * "The Git Parable"

> Functionally, all the commands merely manipulate these properties. If these
> properties were summarize in context one would expect that would represent a
> very complete functional model of Git. A user could review the description
> figure what they wanted to do and then find the command(s) to accomplish it.

I disagree.  While understanding underlying concepts of Git helps with
finding a way to get what one wants to achieve, I don't think that the way
presented here would work in practice.

> Presently this knowledge is accreted over time as oppose to merely being
> read and in the space of a few minutes "groked" (of course it could be that
> I am particularly limited :).

It is documented, see referenced mentioned above.

> For example, towards a functional model, is this close? (note: all
> properties can be blank/empty)...
> 
> REPOSITORIES
> 	Collection of Commits

Direct Acyclic Graph of Commits, where edges in graph point from commit
to zero or more its parents.

> 	Collection of Branches
> 		-- collection of commits without children

Errr... what?  Commit doesn't *have* [pointer to] children.  Also branch
can point to commit for which there exists other commit which has given
commit as parent (up-to-date or fast-forward situation, e.g.)


    a---b---c            <--- branch_a
             \
              \-d---e    <--- branch_b

Branches (or branch heads / branch tips) are named references into DAG
of commits, points where DAG of commits grow.

> 		-- as a result each commits either augments
> 		-- and existing branch or creates a new one

Commits do not create a new branch.  New commits must be crated on
existing branch (or on unnamed branch aka detached HEAD, but that is
advanced usage).

> 	Master Branch
> 		-- typically the publishable development history

TANSTAAMB. There ain't such thing as a master branch. ;-)))))

Well, at least not in a sense of there being a branch that is a trunk
branch distinguished by _technical_ means.

> 
> INDEX
> 	Collections of Parent/Merge Commits
> 		-- the commit will use all these as its parent

No.  The index is set of versions of files (blobs) that would go as
a contents (tree) of a next commit (if you use "git commit', not 
"git commit -a").

> 
> 	Staged Commit 
> 		-- these changes are shown relative to the working tree

Errr.... what?

> 
> 	Default Branch
> 		-- the history the staged commit is suppose to augment

Errr... what?

If by "default branch" you mean "current branch", it is currently checked
out branch, where new commit would go, pointed by HEAD symbolic reference.


> WORKING_TREE
> 	Collection of Files and Folders
> 	
> 
> As far as I can tell, the working tree is not suppose to be stateful, but it
> seems the commands treat it as such.

Stateful?

Working tree / working area is a working area.  It can be disconnected from
repository via core.worktree, --work-tree option and GIT_WORK_TREE 
environment, see also contrib/workdir/git-new-workdir


> Again, thanks for your patients.

patience.

-- 
Jakub Narebski
Poland