Why does Source Tree Git Pull require pulling twice?

[davidbjames]

Perhaps this is a bug report, but I was unable to report via recommend "support" site due to Create Issue errors, so here is my report/question.

Git pull frequently fails on first attempt.

Git pull frequently fails on the first attempt, but then works on the second attempt. It's as if Source Tree is dependent on doing the initial fetch to determine what needs to be pull from remote, so that if you Pull before that has fired then it errors out. By the same token, by the time the Pull is attempted Source Tree indicates it knows what's on the server (via the badge icon) and then it works on the second Pull. See screenshot of error.

[Seth]

If you do a "git pull" command from the command line, that is basically a shortcut for doing a "git fetch" (update refs from the remote) followed by a "git merge" (apply new commits from remote branch to local branch).

SourceTree appears to be trying to help prevent you from pulling unexpected information. It runs a separate "git fetch" command before the pull, and if the fetch finds changes, then that means there are commits that you would be pulling that weren't previously being displayed in your graph, so it aborts. However, the fetch does successully update your copy of the remote data, so a second pull works.

Two potential solutions:

1. Get in the habit of hitting the "fetch" button and double checking changes before hitting "pull".

2. Turn on the option to "Check default remotes for updates every __ minutes".

[davidbjames]

Thanks for the answer, though I don't think SourceTree should be interferring under the guise of being helpful. Most users know what git pull means (fetch+merge) and they probably don't really care what's coming down the line just that it works. Better to give users freedom instead of putting in unecessary controls.

[Seth]

You're probably right, but I think you'd be surprised how little many users know about Git. At least part of that is because tools like SourceTree make it so easy to use despite having little knowledge of how the basic operations differ from traditional systems (like SVN).

You can try submitting reports at both jira.atlassian.com and support.atlassian.com, though Jira seems like a better location for this (feature/change request).

[davidbjames]

For the record, Fetch'ing has the same problem.

I would appreciate if someone from Atlassian could move this to a bug report. I attempted it and got errors on the create ticket form.

[benxtan]

Yea I'd also like this to be "fixed". Perhaps there can be an advanced user setting in SourceTree that automagically does the fetch?

[benxtan]

Oh wait...I see you are getting an error on the fetch too. Interesting.

[KieranA]

I just searched for the error message and got this:

http://stackoverflow.com/questions/11796580/git-pull-error-error-remote-ref-is-at-but-expected

This isn't a SourceTree bug, it's something Git is doing. Remember, it's just a Git call - if an error gets spat back out from there it's being generated from Git itself. One thing to try would be issuing the same calls from the terminal to see what it does, too.

(I'm a SourceTree dev)

Cheers! :)

[davidbjames]

I'm convinced this is a SourceTree bug. It does not occur on the command line, nor does the ref'd SO article apply in my situation. Nor is the Git command used by ST just a simple command. I really think it's a timing issue. If I open the repo window in ST and hit pull on the branch I get the error while ST is doing some kind of async git operation in the background. Once ST has finished it's thing, the second pull works.

[Seth]

Just to make sure the Git command line isn't suffereing from the same issue, make sure your test case has the following steps in the exact order:

1) Have a colleague push a change to the remote

2) Fetch (you should see that there is a change to pull)

3) Have a colleague push another change to the remote

4) Pull via command line (do not fetch)