Re: Hey - A Conceptual Simplication....

[Jakub Narebski <jnareb@gmail.com>]

Side-note: you are employing very strange line wrapping... you should
word wrap your lines so they do not exceed 70-76 characters, and you
should not (except when required for readability) rewrap quoted text.

On Thu, 19 Nov 2009, George Dennie wrote:
> Thanks Linus, Jason, and Jakub...
> 
> Linus Torvalds wrote....
>>On Wed, 18 Nov 2009, George Dennie wrote:
>>> 
>>> The Git model does not seem to go far enough conceptually, for some 
>>> unexplainable reason...
>>
>> Others already mentioned this, but the concept you missed is the git
>> 'index', which is actually very central (it is actually the first
>> part of git written, before even the object database) but is
>> something that most people who get started with git can (and do)
>> ignore. 
> 
> Uhmmm, subtle. I hear you. Thanks for the heads up. But before that,
> I just put these two cents down... 

> [...] Now, I have not had occasions to do merges, as such. So I am
> finding the justification for the index vague. [...]

Errr... you didn't do any merges?  What is then your experience with
using version control, then?


As for using index during merge: merge is joining two (or more) lines
of history (lines of development), bringing contents of another branch
into current branch.  Some of changes are independent, for example
if one branch changes one file, and other branch changed other file.
This is so called trivial merge, example of tree-level merge.  Even
if branches merged touch the same file, if changes were made in separate
sections of file git can merge changes (using three-way merge / diff3
algorithm).

The problem starts if there are changes which touch the same sections
of a file.  This generates so called merge conflict (contents conflict),
and you have to resolve such conflict manually.

During merge index helps to manage information about yet unmerged parts.
Let's assume for example that you made a mistake in merge resolution in
some file, and you want to scratch your attempt and try it anew. 
Without index it would be very hard to do without trashing resolutions 
of other conflicts.

> For example, the functional notion of the repository seems well
> defined: a growing web of immutable commits each created as either
> an isolated commit or more typically an update and/or merger of
> one or more pre-existing commits.

If by "web" you mean DAG (Directed Acyclic Graph) of commits, then
yes, it is _part_ of repository.

There are also refs (branches, tags, remote-tracking branches), which 
are also part of repository, very important part.  Those are named
references into DAG of commits.


As to commits being created as update of existing commit or from 
scratch: that would depend on the way of development.  Merge commits
are much, much more rare than ordinary commits (especially that git 
favors fast-forwards by default when there is no need for merge).

> 
> With such a description the rest of the structure becomes almost
> implicit: Commits may be annotated such as with release number labels.
> Commits that have not been linked to such as by an update or merger
> remain dangling like loose threads in the web and are called branches.
> Branches may be given special labels that the repository will then
> automatically update so as to refer to the latest commit to that
> branch.      

Almost right.
 
> I don't yet have such a clear model for the index. Yes it is a staging
> platform, but so is the IDE....I'll do more reading. 

The index is area where you prepare commits, if needed.  But you
don't need to care that there is something like the index, and prepare
your commits in working area.  But when you need it, it is there.

-- 
Jakub Narebski
Poland