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