Re: fetch and pull

From: Jay Soffian <jaysoffian@gmail.com>
Date: Mar 16, 2009, 22:14 UTC
Message-ID: <76718490903161514ubbdc948o1a0251212fe65fea@mail.gmail.com>
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E70A2AF023@EXCHANGE.trad.tradestation.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.