Re: Hey - A Conceptual Simplication....

From: Jakub Narebski <jnareb@gmail.com>
Date: Nov 19, 2009, 10:27 UTC
Message-ID: <200911191127.28768.jnareb@gmail.com>
In-Reply-To: <009401ca68bc$7e4b12b0$7ae13810$@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:

Show 16 quoted lines

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

Show 8 quoted lines

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