Previously, the content-encoding header was removed and the body
was modified, but the content-length header was not modified,
resulting in the content-length header not matching the body
length.
Fixes [Bug #16672]
a7cb30124c
In https://github.com/rubygems/rubygems/pull/4152 `bundle config` was changed
to default to local scope (instead of global) if the command was executed
from inside an application directory.
Updated documentation reflects this change.
d92d42cae5
This is hiding a real bundler issue as a "network error". It's more
helpful to get a proper bug report, with stack trace and so on.
So stop re-raising errors when evaluating unmarshaled responses as
network errors, and only raise Marshal errors when the Marshal format is
invalid, not whenever marshalled gemspecs can't be loaded because that
may hide actual client errors, like missing `YAML` constants.
05ea907e1c
Properly set the name of `File::Constants`, which is the only name
with a namespace in `RDoc::KNOWN_CLASSES`, and fixes longstanding bug
that `File::Constants` becomes `File::File::Constants`.
When it is generated by `rb_file_const` in dir.c, `name` is set to the
qualified name as same as `full_name`, and generated in the normal way
in file.c later, already set `full_name` is cleared and `name` will be
constructed from the enclosing namespace and the `name`. It will
results in duplicated namespace, `File::File::Constants`.
3a8d6df562
The note
> Raises an ArgumentError if the given +orig+ is immutable, such as Symbol,
> Integer, or Float.
has not been true since #2313 (GH-2313, Feature #16035) when
@casperisfine enabled storing non-finalizable objects in the underlying
`ObjectSpace::WeakMap`.
On Ruby 2.7+, `WeakRef.new(1) + 1` works fine and the result is the
expected 2.
For example, consider the following markup:
C1#m(a, b)
Before this patch, it generated this HTML:
<p><a href=\"C1.html#method-i-m\"><code>C1#m</code></a>(a, b)</p>
Which places the method arguments outside of the link.
Now it generates this HTML:
<a href=\"C1.html#method-i-m\"><code>C1#m(a, b)</code></a>
05a2b2222b
When I run bundle install with BUNDLE_DEPLOYMENT=true in the environment
on a different platform than I usually do development, I get the
following output to the console (wrapped exactly as shown):
Your bundle only supports platforms ["x86_64-darwin-19"] but your local platform
is x86_64-linux. Add the current platform to the lockfile with `bundle lock
--add-platform x86_64-linux` and try again.
Because the way the message wraps, its not as simple as copying the
suggested command to the clipboard because it contains a newline:
$ bundle lock
Writing lockfile to [...]/Gemfile.lock
$ --add-platform x86_64-linux
Adding a newline right before the command forces the command in the
error message to be on the same line, which facilitates copy-pasting the
command in the message.
4cf6989b11
Previously they had slightly different behavior when combined with
conservative updating flags.
The correct behavior is the `--update-strict` option, so `--script` now
does that, The `--update-strict` option is left there for now but I will
deprecate it later.
ab42046229
The existing implementation, given the below .inputrc, erroneously
creates a "C-v" key binding:
set keymap emacs-ctlx
"\C-v": "[C-x C-v was pressed]"
This fixes it to instead create a "C-x C-v" keybinding.
719f52d231
