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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html