Jon Forrest <nobozo@xxxxxxxxx> writes: > "If Bob’s work conflicts with what Alice did since their histories forked," > > Does this include both changes that Alice has checked in to > her repository and uncommitted changes in her working tree? Git will not allow you to do a "git pull" if your uncommited changes touch the same files as the pull. So, you basically can't have conflicts about uncommited changes with "git pull". That's by design: solving conflicts can be hard, and you want the "last commit" safety net while doing it. If you mess up your conflict resolution, you can still "git reset --merge" and try again. > "Alice will use her working tree and the index to resolve conflicts," > > How does Alice use her working tree and index? Does this mean > she makes changes to her working tree so that the conflicts > no longer exist? Yes. > How does the index play a part in this? Once the conflict is fixed in the working tree, you run "git add" to mark the conflict as resolved. And before this, the index contains half-merged versions of your file, and "git diff" can show you the difference between them and your worktree. See the user manual : http://schacon.github.com/git/user-manual.html#resolving-a-merge (BTW, that's not the official place for Git documentation, but since kernel.org is down now ...) > "and existing local changes will interfere with the conflict > resolution process" Probably this should have been "would have interfered" (and therefore are forbidden by Git, as the following sentence says): > "(git will still perform the fetch but will refuse to merge > --- Alice will have to get rid of her local changes in > some way and pull again when this happens)." -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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