Re: Terminology question about remote branches.
- From
Julian Phillips <julian@quantumfyre.co.uk>
- Date
- Aug 4, 2007, 14:50 UTC
- Message-ID
- <Pine.LNX.4.64.0708041542270.11191@beast.quantumfyre.co.uk>
- In-Reply-To
- <85y7grfkbe.fsf@lola.goethe.zz>
On Sat, 4 Aug 2007, David Kastrup wrote:
Show 35 quoted lines
> 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
> 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