Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Cannot pull with rebase: You have unstaged changes.

Rob Wilkerson February 6, 2013

I highly doubt that this is a SourceTree issue, but the colleague who is reporting this issue is using SourceTree installed git and I can't find any answers anwhere else, so I thought I'd try the experts here. The guy is trying to do a simple pull. What he gets, in several different repositories is:

Cannot pull with rebase: You have unstaged changes.

Doing a git status reports that:

# On branch master
# Your branch and 'origin/master' have diverged,
# and have 3 and 1 different commit each, respectively.
#
nothing to commit (working directory clean)

Doing a git reset --hard makes no difference.

There is no output from any of this either:

git update-index -q --ignore-submodules --refresh
git diff-files --ignore-submodules
git diff-index --cached --ignore-submodules HEAD --

Sometimes, but not every time, I can do a git pull --no-rebase and it will work, but that's a workaround (and not even a consistent one).

Has anyone ever seen anthing like this? This has been going on for several months and I'm at a complete loss. Something is very wrong, but I have absolutely no idea what.

5 answers

1 accepted

0 votes
Answer accepted
Rob Wilkerson February 22, 2013

Unfortunately, I was never able to find an "in-place" solution for this issue. I ended up re-cloning the repository locally (it had previously been accessed on a networked Linux machine via Samba) and creating a Vagrant dev environment.

So far, no issues.

KieranA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 24, 2013

Were you using a mounted network drive in this instance? It's known to be very problematic when it comes to Git/Hg.

KieranA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 24, 2013

Yeah if you use a mounted network location as your repo location you will most likely encounter problems. This isn't something we support as we have no control over it. Typically we suggest cloning locally because it's so problematic. Your error does seem strange in this case, but what generally happens is that your repository gets corrupted. I'd suggest your solution is the correct one. Many people want to be able to do this, but it's a limitation of a NFS, really.

Rob Wilkerson February 24, 2013

Thank, Kieran. It's helpful to understand the "why" behind the error.

Rob Wilkerson February 24, 2013

Yes. For various reasons, some our internal development occurs on a Linux box mounted via Samba. It's only been a problem for this one user's Mac. Other Mac and Windows users have been able to use it fine which led me to believe that it was more surgical in nature, I suppose.

Joe Pallas June 18, 2015

A long time has passed. I have been seeing this problem on MacOS Yosemite using an NFS-mounted repository. But the problem never occurred if I ran git from the terminal. So I switched SourceTree from embedded git to the system git "git version 2.3.2 (Apple Git-55)" and it looks like the problem went away. The embedded git is 2.2.1 in SourceTree 2.0.5.

0 votes
Henrik February 3, 2015

A coworker is experiencing this once or twice a day on his Windows machine.  He runs git under cygwin, and the repo is locally on his C: drive.

0 votes
Jaxmetalmax May 22, 2013

In the workflow you first commit any change and then rebase, if you don't want to commit the changes you can stash, then rebase, and then pop stash, this problem happened to me using tortoisegit as well, this is not a sourcetree problem, or a problem with the network drive.

0 votes
Tomasz B May 22, 2013

Hi,

I had the same problem. In my case I fixed it by adding noatime to the mount command for nfs share I was working on.

mount -t nfs -o noatime,... device destination

0 votes
KieranA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 6, 2013

Hey Rob,

Have you tried doing

git fetch
git rebase -p origin/master

That may work in your case, although you may have already tried that.

Rob Wilkerson February 6, 2013

We pull via rebase by default so, if I remember my flags correctly, I've effectively tried this. The only new component is the fetch which I've tried. What I can't figure out is just what Git thinks has changed. I haven't found any way to get it to tell me.

Thanks.

KieranA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 10, 2013

Next step would be to check your .gitattributes (in the repo) and .gitconfig for any weird line ending conversion settings that may be wrong. Also, if you're mixing git versions (embedded and system) then this could cause problems.

Rob Wilkerson February 11, 2013

No .gitattributes in this particular repository so there shouldn't be anything funky going on there. I do have filemode set to false, but I've never had that be an actual problem. If I turn it on, git status reports changes. Turn it off and it doesn't. Pretty much exactly what I'd expect.

I'll take a look at the guy's text config setting, but it still seems like git status should report a change if one was made. In this case, git seems to be talking out of both sides of its, ahem, mouth. No changes, says git status, but yet changes are preventing a pull. **confused**

Thanks for your help.

stevestreeting
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 11, 2013

I wonder if you set filemode to true, then use git reset --hard, will it solve the problem? I'm just wondering if git isn't *completely* ignoring those file mode changes.

Rob Wilkerson February 11, 2013

Thanks, Steve. Another good thought that I don't think I've tried. I'll give it a shot today.

Rob Wilkerson February 11, 2013

Also, I should have mentioned in response to Kieran, he is using embedded Git (1.7.11.1). He does not have another Git executable on the system. And Steve, I was wrong. He has filemode set to true for this particular repository. Any idea how I can do a git reset --hard in SourceTree? I'm a CLI geek so navigating the GUI is foreign to me. I may find it by the time you respond, but I thought I'd go ahead and toss out the question in case I don't.

stevestreeting
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 11, 2013

There are a couple of ways - you can hit the Reset toolbar button then select the 'Reset All' tab. Alternatively you can right-click on a commit in the log view and select the 'Reset <branch> to this commit' option to reset to somewhere else, when you get the traditional soft/mixed/hard modes as an option.

Rob Wilkerson February 11, 2013

Okay. I did try the toolbar, but it's disabled (presumably because git status returns no deltas). I'll check the other, but I suspect I'll get the same result. Thanks.

stevestreeting
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 11, 2013

Yes, Reset is diabled when there are no changes, but if you changed the git filemode option then the changes should appear?

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events