On Mon, May 09, 2011 at 03:46:19PM -0700, Junio C Hamano wrote: > > Interesting. Is your fetch from "ko" a no-op, or are you using it to > > syncrhonize development between different machines? > > Preformatted html and man pages are made when I push the integrated source > branches out, triggered from the post-update hook at kernel.org. I do not > format them on my box. Ah, that makes sense. > > I think it is important to note that calling them both "origin" is > > definitely the wrong thing. The proposal is instead that "git push" > > without a remote would default to something besides "origin". For people > > who publish multiple places, it might even make sense for it to be an > > iterative push to each place. > > Either we add branch.<name>.pushremote or push.defaultremote then? I don't think most people would want just branch.<name>.pushremote. They are more likely to want to always push to some place, so push.defaultremote is a better choice. But that has weird precedence problems. We auto-create branch.*.remote, so if branch-specific config takes precedence, their push.defaultremote will almost never be used. And if branch-specific config _doesn't_ take precedence, then that is weird and unlike almost every other part of git. Another option is to mark the remote with an explicit "don't push here, push to this other remote instead" config, like: $ git remote add my-fork host:project.git $ git config remote.origin.pushremote my-fork $ git push ;# acts as if you did "git push my-fork" And then when we default to a remote, either because it is "origin" or because it is in branch.*.remote, then we will end up pushing to the right place. I'm unsure what should happen in the case of: $ git config remote.origin.pushremote my-fork $ git push origin In the workflow we described, "origin" is simply not a push-able remote, so it is a slight convenience to intercept all pushes for it and transparently rewrite them to "my-fork". And it makes the concept of that config slightly simpler. It basically becomes the equivalent of remote.*.pushurl, except that we are clear that it is a totally separate remote with different tracking branches. But it does eliminate any workflow where "origin" is _sometimes_ pushable, but you almost always want to push somewhere else instead. Because you have no way to push to "origin" now. I don't know of any such workflow, but I hate to be restrictive for no good reason. If it just handles "use this remote instead only in the case of a default selection", then the name should probably be like "defaultpushremote" or something. -Peff -- 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