From: David Woodhouse <dwmw2@infradead.org>
Date: Sun, 06 May 2007 08:39:19 GMT
Subject: Re: 'upstream' branches.
Message-ID: <1178440759.17680.112.camel@shinybook.infradead.org>
In-Reply-To: <7vy7k2e606.fsf@assigned-by-dhcp.cox.net>

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