Re: Question on multi-level git repository heiarchy.

On Friday 2006 October 27 15:05, Ben Greear wrote:

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

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.

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