Quoting John Dlugosz <JDlugosz@xxxxxxxxxxxxxxxx>: > My concern is that you establish your working state based on the local 'master', only to immediately change it again when the pull updates master. But that's the way it's supposed to work? > > I think the documentation for git-pull might also be garbled from text being of different eras. "Normally the branch merged is the HEAD of the remote"? That will be basically random since the last thing the upstream repo user did will control what his HEAD is. That's how it's supposed to work, and the documentation isn't from a different era, either. Majority of users clone from a central repository and keep pulling to update their clones, and in that kind of setting, HEAD will never change. A HEAD in a bare repository tells people which branch is the primary branch of the project. I think you are confused because you are thinking that it's typical to pull from a live repository that has a working tree somebody else uses to grow his history, and you are correct that you can't predict which branch HEAD points at at any given moment. But that isn't how a typical workflow uses pull and push between repositories. -- Nanako Shiraishi http://ivory.ap.teacup.com/nanako3/ -- 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
