how do you "force a pull"?

I am working in repo1, and make a savepoint commit and pack up and leave.

On another machine, I have a clone of repo1 (repo2). So I pull from repo1, "git reset --soft HEAD" to get rid of the savepoint commit, and start working in repo2.

A while later I realize the earlier commit was actually a good commit point. But I can no longer pull it again from repo1. It keeps giving me the "Cannot merge" fatal error. "-f" doesn't help.

So in general my question is "how do you force pulling from a remote repository?" (short of, you know, recloning the repo...)

I have a feeling that either I'm still stuck in the traditional central-repository mentality, or missing something real simple.

Thanks.

On 8/25/07, Jing Xue <jingxue@digizenstudio.com> wrote:

I've had the same trouble and it also brings up the question, why
can't one fetch into the current branch? To work around git pull's
behavior, I generally either:
- git reset --hard HEAD^^^^^^^ && git pull
 or
- git checkout someotherbranch && git fetch -f origin master

So why doesn't pull -f understand that it should force an update to the history? And is there some reason I'm missing for why fetch won't fetch on the current branch?

The commit you pulled should still be in your local repository (repo2), unless you've done something to deliberately remove it.

If you're using the default repository setup when cloning, then master branch of repo1 should be available as origin/master, so you can do the following:

$ git reset --hard origin/master

or log:

$ git log origin/master

If you want to see all your branches, local or remote:

$ git branch -r

Note that you shouldn't checkout origin/master and work on it, but rather you'll want to make a branch, and work on that:

$ git co -b fancy_branch origin/master

You may be getting the "cannot merge message" if you have uncommitted changes, as git won't let you merge when the working copy is changed. git-pull is really git-fetch + git-merge.

On Sat, Aug 25, 2007 at 07:19:46AM -0400, Jing Xue wrote:

On Sat, Aug 25, 2007 at 07:37:47AM -0400, David Watson wrote:

Ah, this is what I was looking for. Not very intuitive, but works like a charm!

Right, because I used "--soft" in the earlier reset.

Thanks!

Jing> Ah, this is what I was looking for. Not very intuitive, but works like a Jing> charm!

I find the word "intuitive" is like "common sense", which apparently isn't very common. :)

"Not very intuitive" can be translated as "I don't yet share the mental model from which this observation would be obvious".

I would suggest that to make such observations more intuitive, you stop thinking of git as you would SVN or (gasp!) CVS, and start paying attention to what git-fetch is really doing to the local object tree, and git-merge on top of that, collectively known as git-pull.

The concept of keeping track of a directed graph of commits is not present in "classic" source code managers... and once you make the mental leap, you'll wonder why it was ever done differently. It's revolutionary, not just evolutionary.

(And if this sounds meta, it's because I'm rewriting my "intro to git" slides because I just confirmed where my next presentation will be, and want them to be even better.)

Jing Xue <jingxue@digizenstudio.com> writes:

This is probably not as good an answer as David Watson's suggestion, but if what you want is to commit your current code while still having your savepoint commit in the history, shouldn't you be able to commit your current code and then use git-rebase to rebase it onto the savepoint commit?

Fredrik Tolf

On Sun, Aug 26, 2007 at 09:02:54PM +0200, Fredrik Tolf wrote:

Yep, I tried and it works too. A bit more verbose than a hard reset - involved some manual merging in my case, had to update-index and then --continue the rebase. But then I think this approach is semantically different and probably safer than a hard reset in some cases.

All this is interesting and good to know. Thanks, Fredrik!