Jon Forrest <nobozo@xxxxxxxxx> writes: > I'm reading the git tutorial at > http://schacon.github.com/git/gittutorial.html I recommend reading "Pro Git" book (http://progit.org) > I'm a very literal reader so if something isn't clear > to me, I try to make the effort to understand it. > > In reading about what happens when Alice pulls from Bob, > it says: > > "Note that in general, Alice would want her local changes committed > before initiating this "pull"." > > This is an interesting statement. I'll come back to it shortly. > > "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? Generally Alice shouldn't have uncommitted changes when doing "git pull". > "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? How does the index play a part in this? > I thought that the index gets populated only when a > "git add" is done. Does Alice need to do "git add" as part > of the conflict resolution process? This is actually a very important information. 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. You can see it using "git ls-files --abbrev --stage". The working area gets populated with version that contains both "ours" and "theirs" hunks using conflict markers (the 3-way textual merge, like 'rcsmerge' or 'diff3 -E' does). Sidenote: you can use "git checkout --conflict=merge <file>" to re-create this version if you messed up conflict resolution, or even --conflict=diff3 if you want "base" (ancestor) version to be shown in conflict markers as well... but this would discard your changes. After resolving conflict you do "git add" on resolved file to mark it as done. This leaves you with only newly add-ed stage 0 in the index! The pre-commit hook might check if you didn't accidentally marked as resolved (added) file with [something that looks like] conflict markers in it. HTH -- 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