Re: 'upstream' branches.

[David Woodhouse <dwmw2@infradead.org>]

On Sun, 2007-05-06 at 01:00 -0700, Junio C Hamano wrote:
> Ahh, I did not mean by "mtd's idea" _your_ repository, but I
> meant whichever one that was overwriting your 'linus' tracking
> branch you are using to track fetch from Linus's tree.

Ah, right.

> The cleanest way to view "what do we really have since the
> latest of Linus, regardless of how and from whom we learned
> where the tip of Linus is", would be not to let other trees to
> disturb the tracking branch you use for Linus's tree with each
> other.
> 
> 	[remote "a"] fetch = refs/heads/linus:refs/remotes/a/linus
> 	[remote "b"] fetch = refs/heads/linus:refs/remotes/b/linus
> 	[remote "c"] fetch = refs/heads/linus:refs/remotes/c/linus
> 	...

You're speaking from the point of view of the git implementation.
>From the point of view of the _user_, I would violently disagree :)

Having pulled that into my local repository, how do I then set it up to
push the latest commit of refs/remotes/*/linus into the 'linus' branch
of the origin, when I push back to my public tree on the server? Or do
you expect _everyone_ who pulls from that public tree to also do stuff
like:
> 	git log master --not remotes/a/linus remotes/b/linus remotes/c/linus


Can't I instruct it to _merge_ the 'linus' branch of each remote into my
own 'linus' branch? Of course that merge would only ever be a
fast-forward or a no-op, in practice.

-- 
dwmw2