Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
BUNDLED WITH breaks git bisect run #3726
The recent addition of
A possible (albeit cumbersome) workaround would be to make the
(I don’t think this is a duplicate of #3697, as its resolution does not address this problem.)
This does not address the use case above, as (a) this installs gems to
Yes, but this does not address the use case above – the script ran by
Is there a reason why the version information needs to be kept in
(I’m aware that you must be dead tired by the
referenced this issue
Jun 8, 2015
Yeah, I think there's a couple of things going on here.
First, @chastell, I appreciate that you opened a ticket trying find a solution to your
For the record, this change does not break backwards compatibility for Bundler. Version 1.10 will still install gems in exactly the same manner as version 1.0. However, there are some existing
Since this problem applies to all applications, and the 1.10 release just makes the need to handle this situation more common, let's see if there is a shared solution that everyone can use in their
This approach actually solves a more general problem—how can you
In a hypothetical bisecting situation where the failing test being bisected can be run with
#!/bin/bash bundle install bin/rake spec status=$? git reset --hard HEAD exit $status
I've created a ticket to document the process for bisecting while using Bundler over at bundler/bundler-site#160. Thanks for bringing this up!
Well, actually ;) the man page describes a situation where the script needs to alter the state of the tree for a reason, not when one of the tools it uses suddenly starts to make the tree dirty:
– but ok, let’s not split hairs here (also: thanks for taking the time to write the example script!).
I’m still not sure why the version information can’t be put basically anywhere else than in
Basically, It has to be in the lock specifically to keep you from being able to git ignore it :P We need that information checked in to the repo in order to support Bundler 2.0 when it comes out, and putting it in another file would mean it could be ignored or out of date from the Gemfile and lock. It's not fantastic, but it's the best option out of the tradeoffs that we had.
referenced this issue
Jun 17, 2015
We've added workarounds for BUNDLED WITH issues in 1.10.4 and 1.10.5, and the BUNDLED WITH section will no longer be added or updated during