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.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
