From: David Kastrup Date: Sat, 04 Aug 2007 14:25:41 GMT Subject: Re: Terminology question about remote branches. Message-ID: <85y7grfkbe.fsf@lola.goethe.zz> In-Reply-To: <854pjfgzit.fsf@lola.goethe.zz> David Kastrup writes: > "Lars Hjemli" 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? 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? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum