Frequently when I try to commit using Source Tree I get errors like:
git -c diff.mnemonicprefix=false -c core.quotepath=false commit -q -F /var/folders/xc/bgspnlyn75g6cwp06r_lw3nr0000gn/T/SourceTreeTemp.eQpjLF error: unable to create temporary file: File exists error: Error building trees Completed with errors, see above
But if I do the exact some commit using the comand line it succeeds.
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:
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 (v126.96.36.199) there was not version found. Then I installed a new copy via brew (188.8.131.52) 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
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
I'm getting this once again, different repo, but doesn't matter if system or embedded git, no submodules invovled either.
git -c diff.mnemonicprefix=false -c core.quotepath=false commit -q -F /var/folders/xc/bgspnlyn75g6cwp06r_lw3nr0000gn/T/SourceTreeTemp.zmuqvX error: unable to create temporary file: File exists error: Error building trees Completed with errors, see above
I also have this issue very regularly when either using the system git (184.108.40.206) 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
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'm getting the exact same issue. I switched to using System Git (220.127.116.11). 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.
I've also started to get this problem. Tried switching to default System Git 18.104.22.168 (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.
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.
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.
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?
I don't have a launchd.conf but I do set various env vars in my .bash_profile, although I don't think there is anything there that would cause a problem.
This is the majority of my git config if it helps at all:
credential.helper=osxkeychain color.diff=auto color.status=auto color.branch=auto user.name=Tom Beddard core.excludesfile=/Users/tom/.gitignore alias.st=status alias.ci=commit alias.co=checkout alias.br=branch alias.df=diff alias.lg=log -p alias.spull=!git-svn fetch && git-svn rebase alias.spush=!git-svn dcommit alias.timelog=log --pretty=format:'%Cred%h%Creset - %C(yellow)%ae%Creset - %Cgreen%cd%Creset - %s%Creset' --abbrev-commit --date=iso merge.tool=Kaleidoscope apply.whitespace=nowarn github.user=subblue difftool.sourcetree.cmd=opendiff "$LOCAL" "$REMOTE" difftool.sourcetree.path= mergetool.sourcetree.cmd=/Applications/SourceTree.app/Contents/Resources/opendiff-w.sh "$LOCAL" "$REMOTE" -ancestor "$BASE" -merge "$MERGED" mergetool.sourcetree.trustexitcode=true difftool.Kaleidoscope.cmd=ksdiff --partial-changeset --relative-path "$MERGED" -- "$LOCAL" "$REMOTE" diff.tool=Kaleidoscope difftool.prompt=false mergetool.Kaleidoscope.cmd=ksdiff --merge --output "$MERGED" --base "$BASE" -- "$LOCAL" --snapshot "$REMOTE" --snapshot mergetool.Kaleidoscope.trustexitcode=true mergetool.prompt=false push.default=simple core.repositoryformatversion=0 core.filemode=true core.bare=false core.logallrefupdates=true core.ignorecase=true remote.origin.fetch=+refs/heads/*:refs/remotes/origin/* branch.master.remote=origin branch.master.merge=refs/heads/master branch.v1.1.remote=origin branch.v1.1.merge=refs/heads/v1.1 branch.v2.0.remote=origin branch.v2.0.merge=refs/heads/v2.0
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).
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.
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/
I am experienceing the same issue with 22.214.171.124 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.
I've got the same thing happening with 126.96.36.199 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 v188.8.131.52 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
The same thing happened to me, v. 184.108.40.206 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
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.
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)
The message board made me wait 24 hours before posting this reply...
I've been having the problem ever since v1.5 but have upgraded to most point releases as they were made available. Not sure which I was on just before the 1.7.3 update, probably 1.7.1 or 1.7.2
When it's working I actually keep SourceTree running most of the time and only really restart it with a new update. Although I know in the past I have restarted it lots of times without luck trying to find the source of the problem. It seems that once the app gets into a bad state it often stays that way until the next update.
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.
Supported Platforms macOS Sourcetree has a lot to offer and, like many developer tools, finding and using it all can be a challenge, especially for a new user. Everyone might not love ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot