summaryrefslogtreecommitdiff
path: root/man
Commit message (Collapse)AuthorAgeFilesLines
* October manpagesoctober_manpagesDavid Rodríguez2019-10-0150-50/+50
|
* require `rubygems`, not `ubygems`Mike MacDonald2019-09-113-3/+3
| | | | The latter does not work on Ruby 2.6.3.
* Bump man documentation's monthDavid Rodríguez2019-09-0150-50/+50
|
* Revert "Remove now meaningless setting"David Rodríguez2019-08-263-0/+9
| | | | This reverts commit 52c5a0eedec34b5d86464b3cf135dc2002486f1d.
* Remove mention to remembered optionsDavid Rodríguez2019-08-143-22/+15
| | | | And instead educate users on the preferred, non deprecated, way.
* Document upcoming changes to remembered optionsTomoki Aonuma2019-08-143-131/+140
|
* Use a newer debugging gem in docsDavid Rodríguez2019-08-103-3/+3
| | | | So that the examples work in currently supported rubies.
* Commit man pages to source controlDavid Rodríguez2019-08-1051-0/+6357
| | | | | | | | | | | | | | This has the benefit that: * Allows the installation of bundler as a default gem from rubygems to include man pages. * Removes the need to build man pages during our tests. * Makes working with the manifest easier, because we only have source controlled files, and not a mix of source control and generated files. To make sure they never fall out of sync, we replace the previous `man:build` CI task with a `man:check` task that makes sure the generated man pages are up to date.
* Merge #7265Bundlerbot2019-07-311-5/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7265: Fix incorrect sectioning in `gemfile` man page r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that Gemfile's man page has incorrect syntax in the section where examples for `:ref`, `:tag` and `:branch` are given. ### What was your diagnosis of the problem? My diagnosis was that the section was incorrect since the examples were listed as a separate section. Also, the syntax seems incorrect, since building the docs with [ronn-ng]() (something I've been experimenting with lately) gives the following error: ``` $ bin/rake man/gemfile.5 /home/deivid/.rbenv/versions/2.6.3/bin/ruby -S ronn --roff --pipe man/gemfile.5.ronn > man/gemfile.5 warn: unrecognized inline tag: ["p"] warn: unrecognized inline tag: ["p"] warn: unrecognized inline tag: ["p"] man/gemfile.5 ran for 0.000305 0.000038 0.317832 ( 0.317939) ``` ### What is your fix for the problem, implemented in this PR? My fix is to correct the syntax. The comparison of the rendered man page is: #### `bundle help gemfile` (before) ``` (...) branch, tag, and ref You MUST only specify at most one of these options. The default is :branch => "master" For example: submodules For reference, a git submodule https://git-scm.com/book/en/v2/Git-Tools-Submodules lets you have another git repository within a subfolder of your repository. Specify :submodules => true to cause bundler to expand any submodules included in the git repository (...) ``` #### `bundle help gemfile` (after) ``` (...) branch, tag, and ref You MUST only specify at most one of these options. The default is :branch => "master". For example: git "https://github.com/rails/rails.git", :branch => "5-0-stable" do git "https://github.com/rails/rails.git", :tag => "v5.0.0" do git "https://github.com/rails/rails.git", :ref => "4aded" do submodules For reference, a git submodule https://git-scm.com/book/en/v2/Git-Tools-Submodules lets you have another git repository within a subfolder of your repository. Specify :submodules => true to cause bundler to expand any submodules included in the git repository (...) ``` ### Why did you choose this fix out of the possible options? I chose this fix because it seems like the right thing to do. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Fix `git` options examplesfix_gemfile_manpageDavid Rodríguez2019-07-261-3/+3
| |
| * Fix incorrect sectioning in `gemfile` man pageDavid Rodríguez2019-07-261-2/+1
| |
* | Fix typo in binstubs documentationScott Tesler2019-07-291-1/+1
|/
* Remove now meaningless settingDavid Rodríguez2019-07-101-2/+0
|
* Correct default cache pathIvo Wever2019-07-031-1/+1
| | | The default cache path is `vendor/cache`, not `vendor/bundle`.
* Remove global_path_appends_ruby_scope settingDavid Rodríguez2019-05-071-3/+0
| | | | | | | This is a bug fix, so it makes no sense to make it configurable. Also, the fix is unlikely to cause problems other than maybe needing a fresh `bundle install` on some edge cases. So, let's ship the fix and remove the setting.
* Fix typo in file extensionVictor Gama2019-04-271-1/+1
|
* Merge #7127Bundlerbot2019-04-231-1/+7
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7127: Add git and branch options to `bundle add` r=deivid-rodriguez a=tokachev Closes #6841 These changes will allow to add a gem with the git or branch options. ``` bundle add redis --git "https://github.com/redis/redis-rb" --branch "staging" ``` The result in Gemfile will be: ``` gem "redis", "~> 4.0", :git => "https://github.com/redis/redis-rb", :branch => "staging" ``` Co-authored-by: Baumgarten <baumgarten@localhost.localdomain>
| * Add git and branch options to `bundle add`Baumgarten2019-04-131-1/+7
| |
* | Print errors to stderr by default, and remove configuration optionGrey Baker2019-04-121-2/+0
| |
* | Remove `prefer_gems_rb` settinginit_gems_rbDavid Rodríguez2019-04-111-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | In my opinion, it's overkill to provide a setting for how little this setting was doing. Both types of Gemfile are supported and work regardless of this setting. The only difference this setting would make is the warning message one would get when having _both_ types of Gemfiles in the same project. I changed things so that gems.rb is always looked up first, and the warning message in case you have both always tells you to remove Gemfile and Gemfile.lock.
* | Remove `list_command` settingDavid Rodríguez2019-04-051-2/+0
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | The list command was still present (just aliased to `bundle show`), even if the setting was set to false. So the setting was at least super confusing if not just wrong. It also led to misleading situations such as ``` $ bundle list --help (...) NAME bundle-list - List all the gems in the bundle SYNOPSIS bundle list [--name-only] [--paths] [--without-group=GROUP] [--only-group=GROUP] (...) $ bundle list --only-group=development Unknown switches '--only-group=development' ``` So, instead, I enable the new list command _always_ and remove the `bundle list => bundle show` alias.
* Fix docs about `unset` with `--global` / `--local`David Rodríguez2019-03-151-1/+7
| | | | They are actually compatible.
* Rename major_deprecations to silence_deprecationsdeprecation_changesDavid Rodríguez2019-02-211-3/+3
|
* Space after commaDavid Rodríguez2019-02-201-1/+1
|
* Tweak `bundle config` help to use new interfaceDavid Rodríguez2019-02-201-3/+3
|
* Use newest interface to `bundle config` everywhereDavid Rodríguez2019-02-191-19/+19
|
* Merge #6931Bundlerbot2019-01-291-0/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6931: Add patch option in bundle config r=greysteil a=ankitkataria ### What was the end-user problem that led to this PR? Issue #5994 ### What was your diagnosis of the problem? As mentioned by @indirect I added a `patch` option in the bundler config, which by default is false. If set to true, patch level update are preferred if no update levels are specified. ### What is your fix for the problem, implemented in this PR? A patch level config option which can be opted into. Co-authored-by: Ankit Kataria <ankitkataria28@gmail.com>
| * change prefer to patch_prefer and updated help textAnkit Kataria2019-01-271-2/+2
| |
| * update bundle config man pageAnkit Kataria2019-01-241-0/+2
| |
* | Replace unsafe http URLs with https URLsTakumasa Ochi2019-01-283-3/+3
|/
* Test against Ruby 2.6 and RubyGems 3Samuel Giddins2018-12-281-4/+4
|
* add bundle-remove entry to bundler man pagecolby/bundler-remove-docsColby Swandale2018-12-261-0/+3
|
* Merge #6751Bundlerbot2018-10-231-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6751: Fix BUNDLE_PATH_RELATIVE_TO_CWD env variable name r=greysteil a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that an environment variable in the docs does not work. ### What was your diagnosis of the problem? My diagnosis was that its name is incorrect. ### What is your fix for the problem, implemented in this PR? My fix is to fix the typo. ### Why did you choose this fix out of the possible options? I chose this fix because it's the only non absurd fix. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Fix BUNDLE_PATH_RELATIVE_TO_CWD env variable namefix_env_variable_nameDavid Rodríguez2018-10-201-1/+1
| |
* | add docs for configuring bundler folders through ENV varsColby Swandale2018-10-231-0/+14
|/
* Make the equivalent change to `bundle update`David Rodríguez2018-09-181-2/+2
|
* Document the supported optionDavid Rodríguez2018-09-181-2/+2
|
* Update the Gemfile documentation to reflect the addition of TruffleRuby in ↵Benoit Daloze2018-09-091-6/+8
| | | | Bundler
* [Settings] Append the ruby scope on Bundler 2 with a global path settingSamuel Giddins2018-07-291-0/+3
|
* Auto merge of #6513 - agrim123:agr-bundler-remove, r=indirectThe Bundler Bot2018-07-021-0/+23
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add `bundle remove` Features of the command implemented: - Multiple gems support ```bash $ bundle remove rack rails ``` - Remove any empty block that might occur after removing the gem or otherwise present Things yet to implement: - Add `rm` alias. _Optional_ - [x] Add `--install` flag to remove gems from `.bundle`. - [x] Handling multiple gems on the same line. - [x] Handle gem spec - [x] Handle eval_gemfile cases ([one](https://github.com/bundler/bundler/pull/6513#discussion_r195632603) case left) Closes #6506
| * Update documentationAgrim Mittal2018-07-011-6/+4
| |
| * Remove necessary comments and update documentationAgrim Mittal2018-06-281-3/+3
| |
| * Remove necessary comments and update docsAgrim Mittal2018-06-281-1/+1
| |
| * Add gemfile error when gem is not presentAgrim Mittal2018-06-281-1/+1
| |
| * Update documentationAgrim Mittal2018-06-281-2/+11
| |
| * Add man page for removeAgrim Mittal2018-06-281-0/+16
| |
* | Auto merge of #6613 - kemitchell:mention-show-sorts-in-doc, r=colby-swandaleThe Bundler Bot2018-07-011-2/+3
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Document that `bundle show [--paths]` sorts results ### What was the end-user problem that led to this PR? The problem was that I could not tell from the manpage or documentation website whether `bundle show` and `bundle show --paths` would list gems and gem paths in the same order. I am using `bundle show` and `bundle show --paths` to inventory gems that projects depend upon. ### What was your diagnosis of the problem? My diagnosis was that the implementation of `bundle show` _does_ sort results by name, but that the manpage for the subcommand doesn't mention this. ### What is your fix for the problem, implemented in this PR? My fix involved slightly editing the existing manpage for `bundle show`. ### Why did you choose this fix out of the possible options? I chose this fix because the `.ronn` file text matched the current text I was seeing via the documentation website.
| * | Document that `bundle show [--paths]` sorts resultsKyle E. Mitchell2018-06-301-2/+3
| |/
* | Auto merge of #6605 - forestgagnon:refine-gemfile-source-warning, r=segiddinsThe Bundler Bot2018-07-011-0/+13
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | add warning to docs for explicit source gotcha See https://github.com/bundler/bundler/issues/6280 for more context. This PR adds a warning to the Gemfile documentation to more clearly indicate that specifying an explicit source on a per-gem or block basis also makes that scoped source a global source. Also adds a recommendation that users ensure that all gems in the Gemfile are using explicit sources whenever they introduce any explicit source blocks or source directives on individual gems. If the root cause cannot be fixed until v2, I think this gotcha should be documented in all existing bundler versions which have this behavior, which as far as I can tell is all versions supporting explicit sources via blocks/per-gem directives. I believe it merits a warning because the behavior is non-intuitive, and represents a potential security issue if it is not understood and avoided. I don't know how backporting for documentation is performed, so I'm making this PR against master for now. Please let me know if I need to do anything else. ### What was the end-user problem that led to this PR? Unclear behavior when mixing global sources with source blocks, as outlined in https://github.com/bundler/bundler/issues/6280 . No documentation was present that described this behavior. ### What was your diagnosis of the problem? Having docs would have been helpful! ### What is your fix for the problem, implemented in this PR? Add documentation ### Why did you choose this fix out of the possible options? It was suggested that I make a PR to add documentation here: https://github.com/bundler/bundler/issues/6280#issuecomment-400535496 ## To Reproduce ```ruby source 'https://code.stripe.com/' source 'https://rubygems.org' do gem 'fattr' end gem 'mime-types' ``` results in this warning on v1.16.2, telling me that it preferred https://rubygems.org for the `mime-types` gem, which is counterintuitive when looking at the Gemfile. ``` Warning: the gem 'mime-types' was found in multiple sources. Installed from: https://rubygems.org/ Also found in: * https://code.stripe.com/ You should add a source requirement to restrict this gem to your preferred source. For example: gem 'mime-types', :source => 'https://rubygems.org/' Then uninstall the gem 'mime-types' (or delete all bundled gems) and then install again. ``` Here is a Dockerfile that reproduces the issue when built, for source blocks: ```Dockerfile FROM ruby:2.5.1-alpine WORKDIR /test RUN echo $'\n\ source "https://code.stripe.com/" \n\ source "https://rubygems.org" do \n\ gem "fattr" \n\ end \n\ gem "mime-types" \n\ ' >> ./Gemfile RUN bundle install --verbose # the source ambiguity warning doesn't show up on the initial install for some reason RUN rm -rf /usr/local/bundle/**/* RUN bundle install RUN cat Gemfile ``` Here is another Dockerfile that reproduces the issue when built, for a source directive on an individual `gem` function call: ```Dockerfile FROM ruby:2.5.1-alpine WORKDIR /test RUN echo $'\n\ source "https://code.stripe.com/" \n\ gem "fattr", source: "https://rubygems.org" \n\ gem "mime-types" \n\ ' >> ./Gemfile RUN bundle install --verbose # the source ambiguity warning doesn't show up on the initial install for some reason RUN rm -rf /usr/local/bundle/**/* RUN bundle install RUN cat Gemfile ```
| * add warning to docs for explicit source gotchaForest Gagnon2018-06-291-0/+13
| | | | | | | | | | | | | | | | | | This commit adds a warning to the Gemfile documentation to more clearly indicate that specifying an explicit source on a per-gem or block basis also makes that scoped source a global source. Also adds a recommendation that users ensure that all gems in the Gemfile are using explicit sources whenever they introduce any explicit source blocks or source directives on individual gems.
View Lorry Controller Status