On Fri, Jan 30, 2009 at 12:01 PM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > As Peff commented, this would be horribly wrong if the remote has a > different "origin" remote. Not forcing the push does not help either, it > is still wrong. Got it. Here was my impression of the work-flow we're trying to help beginners with: machineA$ mkdir repo machineA$ cd repo machineA$ git init machineA$ add, commit, add, commit... machineB$ git clone ssh://machine1/repo machineB$ add, commit, add, commit... machineB$ git push (And if my impression is wrong, then stop me right here and I'll shut-up on this thread.) In this case, the clone operation sets up the repo on B to fetch all of the branches from the repo on A. But it doesn't do anything to help the user with pushing the repo from B back to machine A. So perhaps: git clone --origin machineA --push-as machineB ssh://machineA/repo [remote "machineA"] url = ... fetch = +refs/heads/*:refs/remotes/machineA/* push = +refs/heads/*:refs/remotes/machineB/* Now fetch and push are symmetric operations on machineB. > But I think there is an even more fundamental problem: You do not want > that default push. We have "push only those refs the remote and the local > repository share" rule for a reason. It is way too easy to publish > something you did not mean to publish otherwise. I don't have a good answer for that, other than to say that if user is setting up symmetric repositories, user wants to push everything. j. -- 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
