Source Tree often fails to commit

pqg November 8, 2012

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.

26 answers

1 vote
LoganBarnett April 22, 2013

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
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.
April 23, 2013

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 April 23, 2013

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 May 3, 2013

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 May 3, 2013

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.

0 votes
jdoconnor October 21, 2013

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
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.
October 21, 2013

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!

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.
October 21, 2013

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

Cheers

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.
October 21, 2013

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

0 votes
jdoconnor October 20, 2013

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

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

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.
October 20, 2013

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 October 21, 2013

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

0 votes
jdoconnor October 17, 2013

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

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.
October 16, 2013

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 October 16, 2013

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 October 16, 2013

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
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.
October 16, 2013

@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 October 17, 2013

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 October 20, 2013

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.

0 votes
jdoconnor October 16, 2013

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.

0 votes
Tom Beddard August 15, 2013

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 August 29, 2013

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

0 votes
tyssen August 6, 2013

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.

0 votes
Ryan Page July 3, 2013

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 July 3, 2013

I am going to try downgrading back to 1.6

0 votes
Tom Beddard May 15, 2013

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
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.
May 15, 2013

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 May 16, 2013

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

0 votes
Sam Sheffield April 28, 2013

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
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.
April 28, 2013

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 April 28, 2013

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

0 votes
Timothy Kelty April 23, 2013

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 April 23, 2013

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

0 votes
LoganBarnett April 21, 2013

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

0 votes
Tom Beddard April 21, 2013

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

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.
April 21, 2013

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
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.
April 21, 2013

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 April 21, 2013

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 April 21, 2013

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
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.
April 21, 2013

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 April 21, 2013

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

0 votes
LoganBarnett April 18, 2013

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 April 19, 2013

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

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.
April 21, 2013

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.

0 votes
Tom Beddard April 17, 2013

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
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.
April 17, 2013

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.

0 votes
Sam Sheffield April 17, 2013

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
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.
April 17, 2013

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 April 17, 2013

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
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.
April 17, 2013

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.

0 votes
LoganBarnett April 16, 2013

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.

0 votes
Timothy Kelty April 3, 2013

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)

0 votes
Timothy Kelty April 2, 2013

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

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.
April 3, 2013

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 April 7, 2013

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

0 votes
Tom Beddard March 3, 2013

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
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.
March 7, 2013

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.

0 votes
pqg November 12, 2012

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.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events