BTW it is customary on git mailing list to send reply not only to git mailing list, but also to all responders (to previous author, cc to list and to others). Jon Forrest <nobozo@xxxxxxxxx> writes: > On 9/23/2011 10:42 AM, Jakub Narebski wrote: >> Jon Forrest <nobozo@xxxxxxxxx> writes: >>> Does this include both changes that Alice has checked in to >>> her repository and uncommitted changes in her working tree? >> >> Generally Alice shouldn't have uncommitted changes when doing >> "git pull". > > That's what the tutorial said but I'm trying to understand > what happens if she does have uncommitted changes. I'm > trying to understand the total picture. If Alice have uncommitted changes, in working tree and/or in the index, what git does is try to merge if possible; if conflict or new versions from "theirs" touch changed file, git refuses to do a merge. The idea is to do merge if possible, but abort if there is any chance that user's changes would be lost. >> When there is a merge conflicts, the index gets populated by more than >> one version: "ours" (i.e. Alice version) in stage 2, "theirs" >> (i.e. Bob version) in stage 3, and "base" (common ancestor version) in >> stage 1. The stage 0, where "git add" / "git stage" puts contents of >> file, is empty. > > I didn't know there were multiple staging areas. Those are called "stages" inside one single staging area (the index). >> You can see it using "git ls-files --abbrev --stage". > > That's very helpful. Also in the case of conflict, "git diff" would show combined diff of changes. Try both on some example. -- Jakub Narębski -- 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