Re: Hey - A Conceptual Simplication....

From: Jakub Narebski <jnareb@gmail.com>
Date: Nov 20, 2009, 00:49 UTC
Message-ID: <200911200149.19528.jnareb@gmail.com>
In-Reply-To: <00d401ca6954$a29fa020$e7dee060$@com>

On Thu, 19 Nov 2009, George Dennie wrote:

Show 6 quoted lines

> 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.

Show 5 quoted lines

> 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.

Show 6 quoted lines

> 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