Source Tree often fails to commit

This is a git failure, and I've only ever heard of it once before, and it was when a mixture of the command line and SourceTree were being used, across git versions which had breaking changes (particularly in submodule support).

Please try telling SourceTree to use your command-line git install, Preferences > Git > Use System Git

pqg

Versions were similar (system 1.7.10.2 vs embedded 1.7.11.1), don't do anything with submodules or the like, but setting it to Use System Git has indeed solved the issue, thanks.

pqg

Versions were similar (system 1.7.10.2 vs embedded 1.7.11.1), don't do anything with submodules or the like, but setting it to Use System Git has indeed solved the issue, thanks.

My guess is maybe a bug / feature in your older version that's leaving temp files around when 1.7.11.1 expects them to be deleted already. Usually mixing versions works fine but occasionally something like this comes up. Glad you have it sorted out.

I get the same error often.

I swtiched to my system git (1.8) and still no luck.

I also have this issue very regularly when either using the system git (1.8.1.3) or the embedded version of git. The error is:

git -c diff.mnemonicprefix=false -c core.quotepath=false commit -q -F /var/folders/5h/v80pmrbj2dl9jyr_xvzjrb800000gn/T/SourceTreeTemp.V5efbX 
error: unable to create temporary file: File exists
error: Error building trees
Completed with errors, see above

Hmm, if after attempting to commit the file exists at the path, I'd try and delete it then try again. That should fix this problem. Recently I've noticed files get locked in the temp path by Git/Mercurial - we need to look into this one.

Any traction on this? It's happening to me so often, I've had to bail on ST for GitX.

Sorry, we've never been able to reproduce this and don't know what it is about the small number of cases this has been reported on that's triggering it. Basically, we're just calling a standard git commit command here so there's no reason git should fail to create a temporary file when called by SourceTree as opposed to being called any other way. I guess potentially the way we're providing the commit message (which is by passing a file to it with -F so that UTF encoding is predictable) could be different to how other programs are calling git commit, but it doesn't cause any problems in the vast majority of cases.

As a completely random outside chance, could you try disabling the automatic remote refresh just in case somehow that's doing something in parallel which is locking the temporary files git wants to use? It's done by un-checking Preferences > Check default remotes for updates every...minutes. You might also want to try disabling the 'Refresh automatically when files change' option. These don't cause problems elsewhere but it's worth a shot just to eliminate it.

I'll try those settings and use it today and see how it goes.

It should be noted that other GUI's I don't have a problem with (e.g. GitX)

That doesn't fix things for me. I still get the error every time I try to commit on every repo I try. It's a real pity because I would love to use SourceTree but it's just not possible with this error

I'm getting the exact same issue. I switched to using System Git (1.8.1.2). I had 1.7.6 on my system (maybe the default OSX?) that may have been messing things up, I've since then moved it off the path. Either way, if I take the commit command that's being attempted in SourceTree and paste it in the command line the commit goes through without error (SourceTree even detects the new commit). Is there some other diagnostic information I can provide to help solve this? It's really hard to include SourceTree in my workflow when the it and/or the repo is in this state.

Sam Sheffield

I've also started to get this problem. Tried switching to default System Git 1.7.10.2 (Apple Git-33) and also to an upgraded version 1.8.2, but no luck.

git -c diff.mnemonicprefix=false -c core.quotepath=false commit -q -F /var/folders/3g/41t0xjyx63q2d9t_6fbcd5gw0000gn/T/SourceTreeTemp.EhwqWt 
error: unable to create temporary file: File exists
fatal: failed to write commit object
Completed with errors, see above

The weird thing about this is that this message is from git, and SourceTree is simply calling git just like on the command line. I don't even know what temp file it's trying to create that would fail in this case, and can't reproduce it - it's clearly only happening for a small number of people, but when it happens it somehow becomes persistent. I'm beginning to think the only way to get more information about it is to look at the git source code to find out what it could be trying to do at this point.

Sam Sheffield

That is weird. It seems to be related to the creation of the temporary commit message. You're right, once the commit message file has been created, the git command runs from the command line just fine. I created my own temporary file in the var/3g/41t0xjyx63q2d9t_6fbcd5gw0000gn/T/ and ran the failed git message from SourceTree again (from the command line, since SourceTree creates new temp files each commit attempt) and it worked fine!

SourceTree must have been able to create the temp file it uses to contain the commit message though (/var/folders/3g/41t0xjyx63q2d9t_6fbcd5gw0000gn/T/SourceTreeTemp.EhwqWt in the case above), because it wouldn't call the git command unless it had successfully done that. I'm not sure that the error from git is actually referring to *that* temp file, but to another temp file it's trying to create itself. The only thing I can think of is that maybe the fact that ST created a temp file just before calling git is somehow leaving a lock on the system temp file system, making git's creation of its own temp file fail. We don't hold any locks or anything though, we just request a new temp file name, write it, then call git. There shouldn't be any timing issues here, but I wonder if a test build with a slight delay inserted might test this odd theory.

I don't know about the others who are having this problem, but my machine is on an SSD drive (well an iMac fusion drive setup), if it turns out to be a timing issue with locks.

We actually test on quite a range of machines from about 2007 to last year's Retina MBP with SSD so it's probably not as simple as just SSD, but I don't think we have any Fusion drive test machines so maybe that's a factor. Thanks for the heads up.

I managed to work around this by stashing and then immediately applying the stash. Whatever's involved with that seemed to clear up the error for now. Will report back if it resurfaces.

Seems like it came back on like my second commit. No dice.

Please can you (and others, if willing) try this test build: http://downloads.atlassian.com/software/sourcetree/SourceTreeDelayTest_20130422.zip

This inserts a 5 second delay between SourceTree generating the temp file used for the commit message, and calling git commit. Obviously this means there will be a 5s delay after you click OK on the commit dialog and this isn't a proposed final solution, we just want to identify if this is some kind of timing issue related to us using mkstemp() to generate a temp file, and git trying to use it directly afterwards. If it definitely fixes it, we can look at more permanent ways to avoid it.

No joy I'm afraid. I just tried the test build and had the same error as usual after the 5 sec pause

Dang. The only thing I've come across which remotely resembles this is http://kerneltrap.org/mailarchive/git/2008/11/28/4258264/thread - but even if there was some similar problem, it wouldn't explain why you can consistently commit on the command line and not in SourceTree, and why I've never seen it in almost 3 years (and presumably, neither have most people).

Is there anything in Console.app which expands on this, anything related to temp files etc?

Tom, could you perhaps try using the exact command SourceTree uses, and for the -F parameter specify a file path that has your commit message in it?

There is nothing logged in the Console app when it happens. I've never had this problem with other Git GUIs like GitHub for Mac or the older Gitx

This is my launchd.conf:

setenv PATH /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/opt/local/bin:/usr/local/git/bin:~/bin:/opt/local/bin:/opt/local/sbin:~/.gem/ruby/1.8/bin:~/dev/jruby/bin:~/dev/duby/bin

My system git is living on /usr/local/bin/git (Homebrew's version). There's a /usr/local/git/bin (note the swap) that's going into the PATH. Maybe that's the issue? I believe I need to relog/reboot to test if that's the problem, which I can't do right this minute (on the clock at work).

Ok, so that solved it for me it looks like. Here's the full sum up of what I did - my setup includes using git as installed through Homebrew:

Move the OSX bundled git off the path
Relog/restart - launchd.conf only gets loaded on login as far as I know
Indicate in SouceTree that it should use the system git (which will be 1.8.x)
Try your commit again

I don't have a launchd.conf, but I do have /usr/bin in my PATH set in .zshrc. I need to keep /usr/bin in my path for other stuff, so I'm going to try just renaming /usr/bin/git to /usr/bin/git-osx (since I'm also using my homebrew version everywhere.

I'll use ST for a while now and see how it goes.

I don't want to hex it...but I've been using it today and it's been working after the rename!

I've converted this to an answer as it may well solve the problem for users. As we can't reproduce the original behaviour (yet) it's tough for us to tell. If this is the solution then I guess shoving the bundled git on the path would break it? Is it reproducible the other way around if you reverse those changes?

Unfortunately that still doesn't work for me

I removed all links to the system git, so when I also removed the package installed git (v1.8.1.3) there was not version found. Then I installed a new copy via brew (1.8.2.1) but still the same error.

It is odd that the error occurs with whatever version of git that is used, system, embedded, brew... and I've never had issues with other programes that hook into git

Sam Sheffield

I wanted to followup to my earlier messages with this update. For some reason, switching to the 1.6.0b2 version for the Mac fixed the problem.

I've spent the past two weeks working with this version without it popping up again.

Wow, WTF?

Can anyone else having this problem try the beta to see if you get the same behaviour? You can find it here (this is b3): http://blog.sourcetreeapp.com/2013/04/25/sourcetree-for-mac-1-6-0b3-now-available/

Unfortunately I still get the error with b3 using the embedded Git or system versions

Sorry this is late. This is reproducable to me if I put the old git back on the path. Just to clarify, I moved /usr/local/git so it would no longer be on the path.

$ cd /usr/local/
$ sudo mv git git.old

Well since upgrading to v1.6 everything is working again! Did you guys ever find out what the issue was with the previous version?

Unfortunately we didn't. Sometimes the issues are related to something which seems totally unrelated and could've been fixed unknowingly, however. It's still an open issue to us if it was to reoccur though. Glad it's working for you now!

Using 1.6.0.1 and it's still occuring for me. Anything else we can try?

Ryan Page2

I am experienceing the same issue with 1.6.2.1 on Mac Mountain Lion. I did not have this issue until I upgraded recently. I noticed while testing out gitflow but now regular commits and merges all give me th same error which appears to be a permission issue. The typically recieve following error:

git -c diff.mnemonicprefix=false -c core.quotepath=false commit -q -F /var/folders/x2/0cn0cd_x6mn8629fqrwdwx9dm81km1/T/SourceTreeTemp.dvLz3A 
error: unable to create temporary file: File exists
error: Error building trees
Completed with errors, see above

while trying to commit or:

error: unable to create temporary file: No such file or directory
error: unable to write tag file
Tagging failed. Please run finish again to retry.

while tyring to finish a gitflow release

The odd part is if I use the git or git-flow command in terminal that is embedded with sourcetree I recieve no errors.

Ryan Page2

I am going to try downgrading back to 1.6

tyssen

I've got the same thing happening with 1.6.2.2 on OS X 10.8.4 and have had to go back to using Git Tower sometimes.

It seems inconsistent as to what commits go through and what don't. For instance after committing via Tower I was able to come back to SourceTree and get a commit to go, but then tried again later with another and got the same problem.

I've just upgraded to v1.6.3.1 via the automatic 'Install and restart...' upgrade prompt and now I'm getting the error again just as I did with the 1.5.x versions of SourceTree.

I've been using 1.6.x absolutely fine until now on OS X 10.8.4

Really strange and a damn shame Will have to switch back to using the GitHub app now

git -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree commit -q -F /var/folders/5h/v80pmrbj2dl9jyr_xvzjrb800000gn/T/SourceTreeTemp.GYYhlh 
error: unable to create temporary file: File exists
error: Error building trees
Completed with errors, see above

Krystof Vasa

The same thing happened to me, v. 1.6.4.1 does NOT fix it. Happens with every repository. The error is the same, though sometimes, I get the opposite error - "No such file or directory" - but the file indeed exists, it's there, containing the commit message...

git -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree commit -q -F /var/folders/nn/1wyjxvb502ngh9kk40mxldvm0000gp/T/SourceTreeTemp.0FdIwL 
error: unable to create temporary file: No such file or directory
fatal: failed to write commit object
Completed with errors, see above

I've noticed this problem is dependant on how I open the sourcetree.app. If I do it from the finder, it will never fail, but from the command line it does. I'm guessing it has something to do with a setting or ENV variable.

SourceTree developer here.

Based on Jay's recommendation, could others try this to see if this is their problem? The question is how are you launching SourceTree, from the terminal or via the application icon? It'd be interesting to know if this is a cause of the problem.

We're still actively looking into the issue and seeking feedback.

Cheers

Actually, thinking back my problems with Sourcetree might have started after I did the auto update and restart for new version releases.

I always start the app from it's icon in my dock. Just now my version is working again after the last update when I chose the install on quit option instead of install and restart for the auto update (v1.7.3)

tyssen

Yeah, I tried that today. Launched SourceTree with Alfred, went to do a commit and got the error, so quit, found the app in Finder and launched it that way, tried the commit again and it went through.

@Tom, what version were you on before? Thanks in advance!

@John, wow. I just tested this and couldn't reproduce. We're going to look at what other variables could have an effect on this.

@kieran if you want my environment, let me know and I'll message that to you.

We've made a test build that has fixed this issue for one user so we'd like to make it public and see if it resolves the issue for everyone else and get some feedback. Here's a link to it. If you could let us know whether it's a yey or neigh then that'd help us progress with this issue.

Cheers!

I'm happy to help test, but the link gives me an access denied error

If you think this message is wrong, {0}.

tyssen

I get: Is this your first time visiting Atlassian Support?

Sorry about that, I'll try and get a public link up and post again as soon as possible.

Here we go, here's an actual public link this time. I've updated my previous post, too.

Cheers

After reinstalling the command line tools, this build seems to work properly for me. (maybe that was an issue all along -- that I never re-installed the command line tools)