On Mon, Mar 16, 2009 at 4:39 PM, John Dlugosz <JDlugosz@xxxxxxxxxxxxxxxx> wrote: > Yes, I do. If the central repository changed dev in some way other than a fast-forward, or if you really messed up your local dev, it still needs to be repointed. > > Remember the overall flow: first fetch (not pull) and then inspect the difference between your dev and origin/dev. Then, change your dev to match. Let me illustrate why this is still probably wrong. I have a clone of git://git.kernel.org/pub/scm/git/git.git. It has the following remote tracking branches: $ git branch -r origin/html origin/maint origin/man origin/master origin/next origin/pu origin/todo origin/master is never reset. origin/pu resets often. When I want to work on git, I typically create a branch from origin/master. In this case, I would almost never want to reset that branch. So I'd typically do: $ git checkout -b topic origin/master $ edit, commit, edit, commit... $ git fetch $ git log origin/master..topic $ git rebase origin/master Rarely, I'll base a topic on origin/pu. And origin/pu might get reset. But even if it were, I wouldn't want to blindly reset my local branch to match, thus losing my local changes. Instead I'd do this: $ git checkout -b pu-topic origin/pu $ git tag pu-topic-base # handy when origin/pu is reset $ edit, commit, edit, commit $ git fetch drat, origin/pu was reset $ git rebase --onto origin/pu pu-topic-base And in the rare circumstance that I really do want to reset a local branch, I'd do this: $ git checkout dev examine, make sure I really want to reset $ git reset --hard origin/dev I can't really think of a good reason I'd want to reset a local branch which I haven't checked out. j. -- 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
