Skip to content
This repository has been archived by the owner. It is now read-only.

Initial implementation for git local repos #1779

Closed
wants to merge 4 commits into from
Closed

Initial implementation for git local repos #1779

wants to merge 4 commits into from

Conversation

@josevalim
Copy link
Contributor

@josevalim josevalim commented Mar 19, 2012

Initial implementation of local git repos. The first two commits
are simply a refactoring. The commit message of the important
commit is copied below for convenience.

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.

josevalim added 3 commits Mar 18, 2012
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.
@svenfuchs
Copy link
Contributor

@svenfuchs svenfuchs commented Mar 19, 2012

@josevalim <3 <3 <3!!1! :)

@josevalim
Copy link
Contributor Author

@josevalim josevalim commented Mar 19, 2012

I have done a pair review on this with Yehuda. I will be merging this shortly. Concerns 1 and 2 above were addressed, another pull request will be provided to enhance bundle config.

@josevalim josevalim closed this Mar 19, 2012
@svenfuchs
Copy link
Contributor

@svenfuchs svenfuchs commented Mar 25, 2012

for the record, it now seems to be:

bundle config local.rack ~/path/to/local/rack
@phlegx
Copy link

@phlegx phlegx commented Feb 13, 2013

Currently we have:

in Gemfile:

gem 'rack', :github => 'rack/rack', :branch => 'master'

and on command line:

bundle config local.rack ~/Work/git/rack

Wondering if something like this is also possible somehow i.e.:

in Gemfile:

gem 'rack', '~> 0.1.2' 

and on command line:

bundle config local.rack ~/Work/git/rack

thank you
p

@indirect
Copy link
Member

@indirect indirect commented Feb 13, 2013

No, that's not possible. The reason git locals work is that Bundler records the sha you were working with locally in your lock file, to make sure that you get that sha when you deploy.

It would completely defeat the point to let you work with a fork locally but then deploy the published gem (without your forked changes) in production. :)

On Feb 13, 2013, at 4:55 AM, Phlegx Systems notifications@github.com wrote:

Currently we have:

in Gemfile:

gem 'rack', :github => 'rack/rack', :branch => 'master'
and on command line:

bundle config local.rack ~/Work/git/rack
Wondering if something like this is also possible somehow i.e.:

in Gemfile:

gem 'rack', '~> 0.1.2'
and on command line:

bundle config local.rack ~/Work/git/rack
thank you
p


Reply to this email directly or view it on GitHub.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants