Re: fetch and pull

[Jay Soffian <jaysoffian@gmail.com>]

On Mon, Mar 16, 2009 at 4:39 PM, John Dlugosz <JDlugosz@tradestation.com> 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.