Re: Terminology question about remote branches.

From: David Kastrup <dak@gnu.org>
Date: Aug 4, 2007, 15:09 UTC
Message-ID: <85odhnfiau.fsf@lola.goethe.zz>
In-Reply-To: <8c5c35580708040735l54d1b9c7i40cd80d7d11e2961@mail.gmail.com>

"Lars Hjemli" <hjemli@gmail.com> writes:

Show 12 quoted lines

> On 8/4/07, David Kastrup <dak@gnu.org> wrote:
>> Can we get merge conflicts
>> with a remote tracking branch, too?  Namely when the remote branch
>> messed with its history, rebased/reverted stuff?
>
> No, since the "fetch" line in .git/config is prefixed by '+', which
> gets translated to the '-f' option for 'git-fetch'.
>
> And this was probably the primary reason for refs/remotes/* in the
> first place: you have a namespace in which there is no chance for
> 'git-fetch' to overwrite local changes (ancient git had no such
> namespace).

Ok, so a remote tracking branch is a forcefully merged branch, so we put it into a separate category where we won't get tempted to have a branch head which will get overwritten.

This whole "remote tracking" appears to be more a matter of _policy_ rather than inherent design. It would appear that local and remote tracking branches have no fundamental differences, they just get different defaults which make it less likely for the first to lose local changes, and less likely for the second to miss remote changes (in particular where those involve messing up the history).

But it would be easy to create chimeras when working outside of the porcelain, right?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum