It is possible to fail a git merge in such a way that Bundler reads the lockfile as valid and legitimate, ignoring the <<<< lines, and ignoring duplicate gem version declarations. In this case, you can get crazy things from install, like a conflict because you are locked to mutually exclusive versions of two gems. We should probably just abort if your lock contains merge artifacts, and give instructions to do the suggested git checkout HEAD -- Gemfile.lock && bundle install.
git checkout HEAD -- Gemfile.lock && bundle install
Grepping for conflict markers would be easy enough, although the suggested fix probably shouldn't be git-specific (could be from another VCS).
Is it not a wider problem that it fails to recognise that the lockfile is not reconcilable if you have the same gem listed more than once with different version numbers? That seems like something that should be checked.
The lock is not able to have the same gem listed more than once as it is generated -- that's only possible if something has gone wrong, like a failed merge. So... maybe. But I don't want to write or maintain code that tries to deal with every single possible thing that could go wrong with the lock. :\
I think it would be a reasonable case to cover, purely because it seems like it would be quite easy to get into that situation and not have conflict markers if you incorrectly resolved a conflict? I can't think of any other things that would go wrong unless you were hand-editing the file, which is a case that doesn't need to be covered.
The thing is... you should never resolve a lock conflict. You should check out a valid lock and then run bundle install so that Bundler can resolve dependencies. If you "resolve" a lock merge conflict by hand, it's extremely easy to end up in a situation where your lock describes a dependency graph that is logically impossible.
Oh, ok, I see. Yeah in that case we should just check for conflict markers. I'd be happy to whip up a patch to do that if you want :)
Issue #2000 Add test for conflict markers in Gemfile.lock
Issue #2000 improve error message
@indirect Any thoughts on this? :) Does it need any more work?
In the pull request we identified that the tests were not as good as they could be. If that's the only outstanding issue I'll fix them tonight and it's good to go :)
Issue #2000 Improve test for conflict markers in lockfile
Raise error if Gemfile.lock contains conflict markers, closes #2000