On Sat, 4 Aug 2007, David Kastrup wrote:

quoted text
> David Kastrup <dak@gnu.org> writes:
>
>> "Lars Hjemli" <hjemli@gmail.com> writes:
>>
>>>>> Was this helpful?
>>>
>>> Talking to myself: obviously not
>>
>> Disagree.  "Does this answer all questions and makes git's behavior
>> perfectly transparent" -- no.  But let's not confuse "magical" with
>> "helpful" here.
>
> Ok, let's have another go.  Maybe I have understood more as compared
> with last time.
>
> git-branch/git-commit -b creates and manages local branches, nothing
> else.  Local branches' defining feature is that they have a branch
> head I can move around myself.
>
> Then there are non-local branches.  Their defining feature is that
> they have no locally moving branch head and _must_ track a remote
> branch.
>
> But local branches _also_ can track the progress/head of a remote
> branch.  Since they have a locally moving branch head, this will often
> lead to merge conflicts which must be resolved.
>
> So this is more or less what I understand now.  There really is no
> difference between "tracking" and "following" as I thought previously.
> It is just that a local branch which happens to track a remote branch
> is basically a remote tracking branch with a head of its own.
>
> Which means it can get merge conflicts.  Can we get merge conflicts
> with a remote tracking branch, too?  Namely when the remote branch
> messed with its history, rebased/reverted stuff?

Well, sort of - they are not really merge conflicts as there is no merging 
involved.  Fetching is strictly an updating process, either we update the 
branch or we don't.

When updating a remote tracking branch there are two possible scenarios:

1) the new head is a superset of the old head (i.e. the old head forms 
part of the history of the new)
2) the new head is not a superset of the old head (i.e. the old head does 
not form part of the history of the new)

The normal case is 1), and we simply update the branch to point at the 
new commit.  However what happens in case 2) depends on the configuration. 
If we have told git to force an update (indicated by the '+' on the 
beginning of the fetch line in the config) then we simply accept the new 
head as with case 1), otherwise we complain to the user and don't update 
that branch

quoted text
> So that the real difference between a local and a remote tracking
> branch is not that the latter tracks a remote branch (the former can
> do that as well), but that the latter has no local branch head and
> that saves us a lot (but not necessary all) merge conflicts?

Yes.  A remote tracking branch is basically a read-only local cache of 
something that exists in some other repository.

-- 
Julian

  ---
If you're going to do something tonight that you'll be sorry for tomorrow
morning, sleep late.
 		-- Henny Youngman
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html