New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial implementation for git local repos #1779

Closed
wants to merge 4 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@josevalim
Contributor

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 some commits Mar 18, 2012

Initial implementation of local git repos.
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

This comment has been minimized.

Show comment
Hide comment
@svenfuchs

svenfuchs Mar 19, 2012

Contributor

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

Contributor

svenfuchs commented Mar 19, 2012

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

@josevalim

This comment has been minimized.

Show comment
Hide comment
@josevalim

josevalim Mar 19, 2012

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@svenfuchs

svenfuchs Mar 25, 2012

Contributor

for the record, it now seems to be:

bundle config local.rack ~/path/to/local/rack
Contributor

svenfuchs commented Mar 25, 2012

for the record, it now seems to be:

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

This comment has been minimized.

Show comment
Hide comment
@phlegx

phlegx 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

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

This comment has been minimized.

Show comment
Hide comment
@indirect

indirect Feb 13, 2013

Member

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.

Member

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 join this conversation on GitHub. Already have an account? Sign in to comment