Overcommit makes it impossible to use Github for Desktop (Mac) to commit

[jakeonrails]

Hi there,

My project uses RVM to manage Ruby and I have Overcommit installed on Ruby 2.2.5, the Ruby my project uses.

When I try to commit using Github for Mac, I get this error:

This repository contains hooks installed by Overcommit, but the `overcommit` gem is not installed.
Install it with `gem install overcommit`.
 (1)

From what I understand the issue is that Github for Mac is not loading up the shell environment (.bashrc/.zshrc) so it does not have RVM on the path.

I have read that you can install overcommit onto the system Ruby but that seems like a hack that will only temporarily work, and would require my team to update their system Ruby with dependencies that may or may not match what we use in our project.

I have tried the following workarounds:

1. Changing the shebang in pre-commit to !#/usr/bin/env rvm 2.2.5 do ruby
2. Changing the shebang to !#rvm-auto-ruby

I have considered replacing pre-commit with a sh script that loads up the RVM env of the project and then runs a copy of the original ruby script through that environment but I don't have the time and don't want to invest it if that won't work or if there is a more obvious solution.

Does anyone have any ideas about how to make Overcommit compatible with both Github for Mac and RVM? Would it make sense to convert the Ruby hooks into shell scripts that:

1. Check the project itself for some sort of metadata about what Ruby to use to run the Ruby scripts
2. Use that Ruby (could be system ruby by default, or RVM Ruby) to then launch the Ruby script

If that is the case, I may be able to hack on this this week in the evenings but don't want to waste my time on something that is a dead end or has a better short-circuit answer.

Thanks!

[sds]

Hey @jakeonrails, thanks for asking a question that I'm sure others are running into as well.

While I haven't tried this myself, it looks like you can use launchctl to set environment variables that are available to all GUI applications started on your Mac.

If you would like to persist those settings across reboots, you can include those environment variables in /etc/launchd.conf.

Hope that helps!

[jakeonrails]

Unfortunately I don't think that's a fix for this problem.

1. It doesn't actually fix this problem in my case. I get the same error message as before.
   • I've ensured that my RVM has the default set to the 2.2.5 version I'm using for my project
   • I've added that line of code to the bottom of my .zshrc and sourced it
   • I've restarted the Github for Mac app
   • I've run the launchctl command from the terminal while Github for Mac was not running, and tried again
2. Even if it did fix my particular issue for this particular project, it doesn't make sense that it would work for other projects on my system using different gemsets or versions of Ruby controlled with RVM.

At the detriment of my productivity for the day I played with the script a bit and I got something to almost work.

I added this code to the beginning of pre-commit:

#!/usr/bin/env ruby

unless ENV['USING_RVM']
  system("export USING_RVM=true && export PATH=\"~/.rvm/bin:$PATH\" && rvm-auto-ruby #{File.expand_path(__FILE__)}")
  exit $?.exitstatus.to_i
end

# Entrypoint for Overcommit hook integration. Installing Overcommit will result

That does work in the sense that Github for Mac shows the output of Overcommit in a popup dialog, but it then proceeds to show it along with the original error message. Then when I open pre-commit the file is reverted to its original status.

Is there a master file that I can "hijack" somewhere that will not be overwritten? I'm assuming that Overcommit is failing the commit because the pre-commit file does not match some template or checksum or something? Am I on the right track?

Thanks again for your help.

[sds]

You are correct that Overcommit overwrites the hook files if they differ from the "canonical" ones. This is important because it provides auto-update functionality (so when you gem install ... a new version of Overcommit, the next time a hook run occurs it'll update the hook files if there were changes).

While I'm sure there's a way to get this to work without needing to hack the hook files themselves, for now you can disable this auto-updating functionality by applying the following patch:

diff --git a/template-dir/hooks/overcommit-hook b/template-dir/hooks/overcommit-hook
index 3010ef7..de52f0e 100755
--- a/template-dir/hooks/overcommit-hook
+++ b/template-dir/hooks/overcommit-hook
@@ -62,12 +62,6 @@ begin
   logger = Overcommit::Logger.new(STDOUT)
   Overcommit::Utils.log = logger

-  # Ensure master hook is up-to-date
-  installer = Overcommit::Installer.new(logger)
-  if installer.run(Overcommit::Utils.repo_root, action: :update)
-    exec($0, *ARGV) # Execute the updated hook with all original arguments
-  end
-
   config = Overcommit::ConfigurationLoader.new(logger).load_repo_config

   context = Overcommit::HookContext.create(hook_type, config, ARGV, STDIN)

Hope this helps!

[jakeonrails]

Very much so, thank you for following up :)

This seems like a very hacky workaround for using overcommit with gui tools. IMnshO, this issue should be re-opened as it is a deal breaker for teams with people who rely on things like Tower or Github for Mac.

[jakeonrails]

@bm5k Can you try this possible workaround? I ended up not needing that code change that I suggested when I discovered it works fine if you:

1. open terminal to the project you want to work in
2. run github . from the command line

Seems like this gets Github to start properly using the environment in your terminal vs the system ruby etc. At least, it is working for me! (I am also using iTerm2 + ZSH).

[cmer]

@jakeonrails I just tried what you suggested and it works. (iTerm2 + Bash)

[barefootford]

Thanks a bunch @jakeonrails You just stopped some extensive hair pulling.

This same setup, $ gitx . works to remove the gem issue if you specify your Git Executable in preferences, Enable Terminal Usage and give GitX a restart.

[bbugh]

@jakeonrails' workaround doesn't work with Atom's Github plugin, however, because Atom does not respect terminal environment variables when starting from the command line (or anywhere).

Is there another way to do this without launchctl or starting from the terminal? Nothing I've tried from here or anywhere will make this work. 😞

I'd really prefer not hacking the hook files, because other team members also use Atom and have the same problem.

[jhaber1]

@bbugh agreed, disappointed that overcommit does not take care of this. Breaking functionality with popular programs and doing nothing about it is frankly ridiculous. I'd choose not to use overcommit, but I can't make that decision.

Spent a number of hours myself scouring resources trying to fix this, here's what I came up with (note: this solution not for everyone as it involves turning off SIP, executing sudos, and potentially breaking other things):

• Follow this guy's steps to disable SIP.
• Go to /usr/bin (or wherever your ruby binary is)
• Back up the binary: sudo cp ruby ruby~
• Remove the original: sudo rm ruby
• Symlink to your project's ruby. For me, that's my .rbenv one: ln -s /Users/jake/.rbenv/shims/ruby /usr/bin/ruby

Actually just remembered that the issue was originally for the GitHub desktop client. Haven't tested it for that, but the above worked for SourceTree.

Edit: this is pretty unsustainable too since every time OS X is upgraded, the symlink gets wiped.

[alfuken]

Unfortunately, the command line trick did not work for me, and I am using SourceTree. But what did worked, and, hopefully, will be helpful to someone else, is installing the overcommit gem into the system ruby. Which is also way less invasive than @jhaber1's approach ;)

Basically, the steps are:

a) if you're not using rbenv or anything like that and use only MacOS built-in ruby:

1. sudo gem install overcommit
2. profit!

b) if you are using rbenv or some other version management tool:

1. run rbenv global (or alike) to get current global ruby version
2. if it is "system": skip to step 5.
3. remember the output version or write it down somwhere
4. run rbenv global system
5. run sudo gem install overcommit
6. if version from step 1 was not "system", run rbenv global <version from step 1>
7. profit!

[avk]

FYI if anything in your overcommit config depends on things in your project Gemfile, like Rails for a test runner, all of the above still doesn't work for me… considering going back to raw git hooks with a symlink. Overcommit doesn't seem worth jumping through hoops for these dependencies.