So I think this project is great! Is there a way to allow hookup to work in a docker-compose environment? ie. can set a way to preface the hookup commands with docker-compose run --rm ENV etc.?

Running hookup while using the GIT_DIR environment variable causes an error due to the way the GIT command is used in hookup.gemspec.

Probably not a bug in the strictest sense, but it's a little inconvenient. Do you have any suggestions for a way around this?

± GIT_DIR=/path/to/valid/non-hookup/repo/.git bundle exec hookup
/var/lib/gems/1.9.1/gems/bundler-1.2.3/lib/bundler/rubygems_integration.rb:223:in `block in replace_bin_path': can't find executable hookup (Gem::Exception)
        from /var/lib/gems/1.9.1/bin/hookup:19:in `<main>'

I tried to use this gem to fix merge conflicts but it was not working as expected.

Merge conflicts on schema.rb were not fixed. I then noticed that the last release of this gem was in 2014 and was missing this fix to handle Rails 5 schema format #39

In the meanwhile I have resorted to installing the main branch:

gem install specific_install
gem specific_install -l https://github.com/tpope/hookup.git
hookup install

Could you release a new version of the gem that includes the current fixes in the main branch?

Thank you for the awesome gem 💚

I personally use a different resolution strategy for both migrations and bundler.

Bundler

1. As of sometime in 1.0, it should be fine to always run bundle install without running the check first. If the check is required, that's a bug. So if the Gemfile changes, it should be equally fast to run bundle install again.
2. If there is a conflict in Gemfile.lock, I propose the following resolution strategy:
   1. git checkout Gemfile.lock -- <older branch>
   2. bundle install
   3. this is because bundler already knows how to resolve conflicts between Gemfile and Gemfile.lock, and will properly handle all the edge-cases we know about

Migrations

For similar reasons, I propose the following resolution strategy for conflicts in schema.rb

1. git checkout db/schema.rb -- <older branch>
2. rake db:migrate
3. Again, rake db:migrate knows how to bring a schema.rb up to date with newer migrations

Is there any reason my thinking here is incorrect?

Hey Tim!

On a project I work on, we use one database per branch, the database name is determined by the project name, part of the branch name and part of everything combined which result in a database name that looks like project_dev_feature_90a8834de76326869.

We do this because we want to make sure that each branch has it's own dedicated database and we do not want to worry much about migrations between features (that can radically change!)

So using Hookup on this project will result in the following:

$ git checkout feature
Switched to a new branch 'feature'
rake aborted!
Unknown database 'project_dev_feature_90a8834de76326869'

Tasks: TOP => db:migrate:down
(See full trace by running task with --trace)
Failed to rollback 20121115215229_add_comments_to_posts.rb

Any suggestions ?

Hi,
I've installed as mentioned in the instructions, and I get error whenever I checkout:

git -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree checkout master 
Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.
  (use "git pull" to update your local branch)
Switched to branch 'master'
.git/hooks/post-checkout: line 2: hookup: command not found
Completed with errors, see above

I use mac.

Any solution?

Hello

$ gco -- db/schema.rb
.git/hooks/post-checkout:116: syntax error, unexpected tSTRING_BEG, expecting keyword_do or '{' or '('
hookup post-checkout "$@"
                      ^

I have the same issue when I change branch. I will try to look at it.

I guess I could remove the gem, but curious if there's an intended way to disable hookup, for quick branch changes, or when migrations aren't finished/easily reversible etc? Just a thought, thanks Tim, great tool!

Hookup doesn't seem to resolve conflicts in structure.sql by rollbacking/migrating when doing a rebase. Steps to reproduce:

• add config.active_record.schema_format = :sql to application.rb
• git co master
• rails g migration createUsers
• Add users table definition
• rake db:migrate
• git ci -am "Create users"
• git co -b new-feature
• rails g migration addNameToUsers
• Add name column to users
• rake db:migrate
• git ci -am "Add name"
• git co master # hookup works here
• rails g migration addAgeToUsers
• Add age definition to migration
• rake db:migrate
• git ci -am "Add age"

So far so good, now either:

• git merge new-feature

or

• git co new-feature (hookup works here)
• git rebase master (but not here)

doesn't seem to trigger Hookup in any way. A conflict in structure.sql is detected and the merge/rebase halts.

Am I missing something? Using git version 2.3.6, ruby 2.2.2 and rails 4.2.1.

I have an existing git script for updating ctags from bundled gems - could hookup provide a hook to call that script when the bundle has changed? Maybe that's too trivial to add outside of hookup...

Since 37f6304, I've started seeing Git errors leak out when the db directory doesn't exist.

fatal: Could not switch to '.../db': No such file or directory
fatal: Could not switch to '.../db': No such file or directory

I want to use hookup on projects without ActiveRecord. @mal, thoughts?

Our app is configured to dump its DB schema as SQL not ruby migrations. Hookup appears to assume that a db/schema.rb file exists, resulting in a error: pathspec 'db/schema.rb' did not match any file(s) known to git. error being thrown when attempting to migrate.

I'll have a stab at modifying it to handle this use case.

It'd be nice for non-Rails projects to just to bundling, or old Rails projects to only to rake db:migrate - I'm working on a gem at the moment where I get pretty frequent "fatal: Could not switch to '/db': No such file or directory" for instance. I can see how'd that'd be useful if I were expecting migrations to run, but I'm not.

RubyGems.org doesn't report a license for your gem. This is because it is not specified in the gemspec of your last release.

via e.g.

  spec.license = 'MIT'
  # or
  spec.licenses = ['MIT', 'GPL-2']

Including a license in your gemspec is an easy way for rubygems.org and other tools to check how your gem is licensed. As you can imagine, scanning your repository for a LICENSE file or parsing the README, and then attempting to identify the license or licenses is much more difficult and more error prone. So, even for projects that already specify a license, including a license in your gemspec is a good practice. See, for example, how rubygems.org uses the gemspec to display the rails gem license.

There is even a License Finder gem to help companies/individuals ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec. This is an important enough issue that even Bundler now generates gems with a default 'MIT' license.

I hope you'll consider specifying a license in your gemspec. If not, please just close the issue with a nice message. In either case, I'll follow up. Thanks for your time!

Appendix:

If you need help choosing a license (sorry, I haven't checked your readme or looked for a license file), GitHub has created a license picker tool. Code without a license specified defaults to 'All rights reserved'-- denying others all rights to use of the code.
Here's a list of the license names I've found and their frequencies

p.s. In case you're wondering how I found you and why I made this issue, it's because I'm collecting stats on gems (I was originally looking for download data) and decided to collect license metadata,too, and make issues for gemspecs not specifying a license as a public service :). See the previous link or my blog post about this project for more information.

I don't see a hookup remove or similar command available. What is the best way to remove hookup from a project? After trying it for a bit I decided I'd rather take care of these things manually to avoid waiting for migrations up and down when trying to quickly change between branches to look at code.

When migrating, Hookup doesn't run Rake under Bundler:

peeja:myapp/ (master) $ git co a-branch
Switched to branch 'a-branch'
rake aborted!
You have already activated rake 0.9.2.2, but your Gemfile requires rake 0.9.1. Using bundle exec may solve this.

(See full trace by running task with --trace)

Perhaps I'm missing something?

From the Padrino guide:

NOTE: we have a namespace for each orm, because of this, Padrino can mount several applications and each of them can use different orms without conflict, so that you can have multiple applications living together and one of them can use DataMapper, while another ActiveRecord/MongoMapper/Couch/Sequel instead. In this way we prevent collisions.

When using, say, ActiveRecord, the migration tasks are found in the ar namespace, not db as hookup is expecting:

$ git checkout foo
Switched to branch 'foo'
rake aborted!
Don't know how to build task 'db:migrate:down'

$ rake -T
rake ar:abort_if_pending_migrations  # Raises an error if there are pending migrations
rake ar:charset                      # Retrieves the charset for the current environment's database
rake ar:collation                    # Retrieves the collation for the current environment's database
rake ar:create                       # Create the database defined in config/database.yml for the current Padrino.env
rake ar:create:all                   # Create all the local databases defined in config/database.yml
rake ar:drop                         # Drops the database for the current Padrino.env
rake ar:drop:all                     # Drops all the local databases defined in config/database.yml
rake ar:forward                      # Pushes the schema to the next version
rake ar:migrate                      # Migrate the database through scripts in db/migrate and update db/schema.rb by invoking ar:schema:dump
rake ar:migrate:down                 # Runs the "down" for a given migration VERSION
rake ar:migrate:redo                 # Rollbacks the database one migration and re migrate up
rake ar:migrate:reset                # Resets your database using your migrations for the current environment
rake ar:migrate:up                   # Runs the "up" for a given migration VERSION
…

Please!

Pinging as instructed. 😺