On Friday 2006 October 27 15:05, Ben Greear wrote: > I want to synchronize the entire git repo, including all branches. How > would I go > about doing that? That happens anyway. "git pull" is actually a fetch + a merge. Personally I recommend never doing a "git pull" without arguments. Instead: First, update every "Pull:" line from .git/remotes/origin $ git fetch Now manually merge one of the (now locally stored) upstream trees into your working tree. $ git pull . upstream-tree > Is there any way to recover my currently mangled tree on the > workstation, or do I need > to start fresh there? If I start fresh, do I re-clone, or is there some > better way to get I'm relatively new to git; my experience is that there is very little that can't be undone. Exactly what sort of mangling has happened to your tree? If you've got yourself in a real state, I suggest editing .git/remotes/origin to pull the upstream trees to some newly named branches (maybe just add "new/" to the front of them). Treat those as read-only (i.e. don't check them out), and start comparing branches. "gitk --all" is incredibly useful for this. Make yourself a new branch for your own work based off a new/upstream branch (git checkout -b fixthings new/upstream), then use git-cherry-pick to pull your patches out of your mangled tree to build up a branch with your changes on it. Now, you can delete all the branches that you think are mangled and (if you really want to), rename all the new/ refs back to whatever they started as. > the synchronization that I want? I am going to guess that you've fallen for the same thing I did at first: confusing "git pull" with "git fetch"; "git pull" can get you in trouble, "git fetch" probably won't. Andy -- Dr Andy Parkins, M Eng (hons), MIEE andyparkins@xxxxxxxxx - 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