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 git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Reply via email to