Re: Hey - A Conceptual Simplication....

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 19, 2009, 21:27 UTC
Message-ID: <7vocmy9pdm.fsf@alter.siamese.dyndns.org>
In-Reply-To: <00d401ca6954$a29fa020$e7dee060$@com>

"George Dennie" <gdennie@pospeople.com> writes:

> REPOSITORIES
> 	Collection of Commits

Ok.

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

Wrong.

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

Ok.

> 	Master Branch
> 		-- typically the publishable development history

Not necessarily.

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

Wrong.

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

A new word for me.  I doubt we need to have such a concept.

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

We typically call it "the current branch". It is "the branch whose tip will advance by one commit when you make a new commit" and determined by HEAD.

> 	Collection of Stashes
> 		-- these are not copies of the working tree since they
> 		-- only contain "versioned" files/folders and so is not
> 		-- a backup

I think it is better to say what these _are_, instead of saying what they are not. These are not yoghurt cups, these are nor bicycles, these are not knitting needles. Listing what they are not does not give you more information.

> WORKING_TREE
> 	Collection of Files and Folders

Ok.

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

I am not sure what you are trying to say by "stateful" here. A work tree has files and directories, and if you edit one of the files of course it changes its state.

----------------------------------------------------------------

A branch is just a pointer to one commit (or nothingness, if it is unborn, but that is such a special case you do not have to worry about yet until you understand git more).

The commit can have many children, but you do not care about them when looking at the branch, as there is no "parent-to-children" pointer.

The pointer that represents a branch moves to another commit by different operations.

 - If you make a new commit while on the branch, it points to the new
   commit.  This is the most typical, and is done by many every-day
   commands, such as "commit", "am", "merge", "cherry-pick", "revert".

   Typically the new commit B is a direct child of the commit the branch
   used to point at A, and B has A as its first parent.

 - There are commands that let you violate the above, i.e. you can change
   what commit the branch pointer points at, and the new commit A does not
   have to be a direct child of the commit currently pointed by the
   branch.  "reset" and "rebase" are examples of such commands and are to
   rewrite the history.

There is the "current branch" that you are on. It is recorded in HEAD (cat .git/HEAD to see it). When you create a new commit, the tip of the branch HEAD points at is updated to point at the new commit. Since the new commit is made a direct child of the current commit, this will appear to the users as "advancing the branch".

The state (contents of files and symlinks together with where they are in the tree) to be commited next is recorded in the index. "git add" and friends are used to update this state in the index, and "git diff" with various options allow you to view the difference between this state and work tree or arbitrary commit.