Now that I have done both methods and I confirmed that the state of the local repo is pretty much the same, either method will work fine for me. I have done this on my working local repo (using way 2) and even pushed it up to the remote just to test it completely. The first method moves (renames) the branch master to parser and then recreates and connects to the remote master branch. The second creates the parser branch and then does a hard reset of the local master branch to the remote master branch. If I'd have known that git branch <new branch name> takes all current local commits into account (which now that I think about it makes sense but I was thinking about it from a remote point of view...) then I might have been able to come up either process. It might have been just a matter of creating the parser branch and then look at the histories of master and parser.
Just have to make sure you local is all checked in or use stash to pop it in later. Thanks RubyRedRick and P Rouleau for your ideas! On Monday, September 10, 2012 10:31:26 AM UTC-7, Patrick wrote: > > ... > # way 1 > 1. git branch -m master parser > 2. git fetch origin > 3. git branch --track master origin/master > 4. git checkout parser > > # way 2 > 1. git branch parser > 2. git fetch > 3. git reset --hard origin/master > 4. git checkout parser > ... > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/nQZf7bczt-oJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
