Source Tree often fails to commit

[pqg]

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.

[LoganBarnett]

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:

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

[KieranA]

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?

[Tom Beddard]

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

[LoganBarnett]

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

[LoganBarnett]

Well I tried reapplying my fix after reapplying the bug, and now it doesn't work, so something else must of have fixed it or it's not a robust fix.

[jdoconnor]

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)

[KieranA]

They wouldn't have had any affect. Installing the command line tools installs stree to /usr/local/bin/. Good to know that the build is working for you, thanks for the feedback!

[KieranA]

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

Cheers

[KieranA]

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

[jdoconnor]

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

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

[KieranA]

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!

[tyssen]

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

[jdoconnor]

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

[KieranA]

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

[Tom Beddard]

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.

[KieranA]

@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.

[Tom Beddard]

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.

[tyssen]

Hit the error message again today when launching SourceTree from Alfred, so tried launching from Finder but this time still got the same error, so I guess that's not actually a reliable solution.

[jdoconnor]

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.

[Tom Beddard]

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

[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.

[Ryan Page]

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 Page]

I am going to try downgrading back to 1.6

[Tom Beddard]

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

[KieranA]

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!

[LoganBarnett]

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

[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.

[stevestreeting]

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/

[Tom Beddard]

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

[Timothy Kelty]

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.

[Timothy Kelty]

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

[LoganBarnett]

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).

[Tom Beddard]

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

[stevestreeting]

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?

[KieranA]

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?

[Tom Beddard]

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

[Tom Beddard]

Creating my own msg.txt file and then running the command that ST uses:

git -c diff.mnemonicprefix=false -c core.quotepath=false commit -q -F msg.txt

works without problem, either using my own message file or the one that ST tried to use

[KieranA]

Have you got a launchd.conf in /etc/? If so, could you paste the contents somewhere for us to see. There could be some vars set there that may affect SourceTree.

[Tom Beddard]

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

[LoganBarnett]

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.

[LoganBarnett]

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

[stevestreeting]

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.

[Tom Beddard]

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.

[stevestreeting]

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.

[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

[stevestreeting]

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!

[stevestreeting]

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.

[LoganBarnett]

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.

[Timothy Kelty]

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)

[Timothy Kelty]

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

[stevestreeting]

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.

[Tom Beddard]

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 :(

[Tom Beddard]

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

[KieranA]

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.

[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.