During the 1.1 pre/RC releases, there were duplicate GIT source sections generated in the `Gemfile.lock`. These would confuse bundler and the wrong source would get attached to the spec. This test case breaks if we don't fix this here: bundler@e31a1c7#L1R51
The proposal of this patch is to implement a functionality that allow developers to work against a git repository locally. This can be achieved by setting up a local override: bundle config rack.local ~/path/to/local/rack Now, instead of checking out a git repository, the local override will be used. This implies a few things: Similar to path, every time the local git repository change, changes will be automatically picked up by Bundler; This means a commit in the local git repo will update the revision in the Gemfile.lock to the local git repo revision. This requires the same attention as git submodules. Before pushing to remote, you need to ensure the local override was pushed, otherwise you may point to a commit that only exists in your local machine. Also, we are doing many checks to ensure a developer won't work with invalid references. Particularly, we force a developer to specify a branch in the Gemfile in order to use local overrides and, if your local repository is on another branch, we will abort. This allows a developer to change between topic or release branches without accidentally changing the reference in the Gemfile.lock. We also ensure that the current revision in the Gemfile.lock exists in the current local override. By doing this, we force the local override to fetch the latest changes in the remotes. There are a few things missing before this change can be merged in: 1) We could improve `bundle check` to validate the conditions above. With this in mind, a developer could add a pre-commit hook that invokes `bundle check` to ensure he isn't pushing an old or invalid reference. However, it will be up to the developer to ensure his local overrides are not dirty or that they were pushed to remote. 2) Currently, every time there is a local override, we are automatically by passing locked specs, regardless if there was a change or not. We need to improve this scenario in order to improve performance. 3) `bundle config foo bar` sets the configuration value for the current user (~). We need to be able to set project configuration and delete them as well.