Re: More Beginning Git Questions

[Jakub Narebski <jnareb@gmail.com>]

Jon Forrest <nobozo@gmail.com> 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