On Sat, 4 Aug 2007, David Kastrup wrote:
David Kastrup <dak@xxxxxxx> writes:
"Lars Hjemli" <hjemli@xxxxxxxxx> 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
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
