Re: git and bzr

[Linus Torvalds <torvalds@osdl.org>]

On Wed, 29 Nov 2006, Johannes Schindelin wrote:
> 
> On Tue, 28 Nov 2006, Linus Torvalds wrote:
> > 
> > The go-to command tends to be "git diff", which after a merge will not 
> > show anything that already merged correctly (because it will have been 
> > updated in the git index _and_ updated in the working tree, so there will 
> > be no diff from stuff that auto-merged).
> 
> This is actually the most meaningful argument for not hiding the index. 
> Usually I explain it to people as a "staging area" standing between your 
> working directory, and the next committed state.
> 
> But I will start explaining the index with "what if your merge failed?".

The thing is, the staging area is needed for a lot more than just merges. 
Every single SCM has one, because even something as _trivial_ as "commit 
all files" actually needs it. People don't just always think about it, and 
the git staging area is "bigger" than most others.

Most other SCM's have a staging area that is just a list of filenames 
(nobody thinks about it, but "commit everything" doesn't actually commit 
everything at all - it just commits everything /in the list of files that 
the SCM knows about/).

Git's staging area is just more complete than most other SCM's. It 
contains not just the list of filenames, but their permissions too (where 
a lot of other SCM's *cough*CVS*cough don't do permissions at all), but 
also their content, and in the case of a merge conflict, the content of 
the base version and the two branches to be merged.

So the index really _is_ required for pretty much all operations 
(including very much "git commit -a", if only because of the filename 
list), but yeah, if you start by talking about merge conflicts, maybe 
people understand WHY it's also important to actually stage the _contents_ 
of a file too (multiple times, in fact, for a merge conflict), not just 
its name.

So most of the time, when you use git, you can ignore the index. It's 
really important, and it's used _all_ the time, but you can still mostly 
ignore it. But when handling a merge conflict, the index is really what 
sets git apart, and what really helps a LOT.

I've used other systems, but the git handling of merge conflicts really is 
superior. Other SCM's think that the merge algorithm is interestign and 
important, and that's bullshit. Merge algorithms are largely trivial and 
uninteresting. The interestign and important thing is to just handle 
failures well, and git does that _really_ well.