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