I don't know of a way. You gotta adapt your thinking: git comes from a world where random beardos are hacking away on the Linux kernel and there is no concept of a master repository. People pull patches from multiple sources and distribute their changes to multiple unrelated groups. In this situation mirroring repositories doesn't make a great deal of sense. PLT's usage is much much much more centralised.
If you want to create a branch that is propagated on the server you have to inform the server of this. This is known as a "remote branch". Eli and I had a discussion about the best way to do this. Here's the soln: git checkout -b branch-name git push origin branch-name --set-upstream First command creates a new branch. The second command sends the branch to the server called origin and tells the local repository to follow changes on the server's branch. Now any changes made on your local branch branch-name can be pushed to the server and git pull will get any changes from the server. HTH, N. On Thu, Apr 22, 2010 at 6:44 PM, John Clements <cleme...@brinckerhoff.org> wrote: > What I learned today: local branches don't get propagated to the master > repository on a 'push' unless there's some remote tag that refers to them. > > I had heretofore assumed that I could use 'git push' in much the same way as > 'svn commit' to guarantee, e.g., that when leaving work nothing was "trapped" > on that machine. IIUC, the behavior of local branches means that this isn't > so. > > Question: is there some easy way to ensure that the local repository is fully > mirrored on the server? Aside from > - not creating branches, or > - hard-coding the list of branches so that they can all be checked? _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
