Re: More Beginning Git Questions

From: Jakub Narebski <jnareb@gmail.com>
Date: Sep 23, 2011, 18:59 UTC
Message-ID: <m3ehz7qe5a.fsf@localhost.localdomain>
In-Reply-To: <4E7CCCA0.50909@gmail.com>

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@gmail.com> writes:

> On 9/23/2011 10:42 AM, Jakub Narebski wrote:
>> Jon Forrest <nobozo@gmail.com> writes:

Show 9 quoted lines

>>> 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.

Show 7 quoted lines

>> 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