On Sunday 14 May 2006 23:20, Junio C Hamano wrote: > Josef Weidendorfer <Josef.Weidendorfer@xxxxxx> writes: > >> ; my private build areas on the kernel.org machines > >> [remote "ko-private"] > >> url = "x86-64-build.kernel.org:git" > >> url = "i386-build.kernel.org:git" > >> push = master:origin > >> ... > > > > specifies that "git push" should push to both URLs? > > Exactly. I would _want_ to push to both with single action when > I say "git push ko-private". Actually I have _never_ felt need > to, but Linus wanted it first and I think it makes sense. Hmmm. Isn't this a solution for a very special use-case? You even can not specify different push lines for the 2 URLs. I think you want an alias name for a group of remotes here? Why not [remotealias "ko-private"] remote = "ko-private-x86-64" remote = "ko-private-i386" Neverless, this wasn't the thing I was after. > That is what "branch.foo.remote = this-remote" is about. OK. Sorry, I somehow missed this. > When > working on foo branch, use what is described in > remote."this-remote" section for "git pull". > remote."this-remote" would have url and one or more fetch lines, > and as usual the first fetch line would say "merge this thing". > This gives the continuity in semantics while migrating from > .git/remotes/foo to [remote "foo"] section of the config file. The only thing I wanted to discuss in this thread is exactly the limitation of "as usual the first fetch line..." by the branch attribute "origin", which lead me to the alternative "tracksremote" attribute. Sorry about any confusion. I suppose "branch.<branch name>.origin" is still the way to go for specifying the upstream? Josef - : 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