Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Abort when lock contains failed git merge #2000

Closed
indirect opened this Issue · 8 comments

3 participants

@indirect
Owner

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.

@zofrex

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.

@indirect
Owner

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. :\

@zofrex

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.

@indirect
Owner

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.

@zofrex

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 :)

@indirect
Owner
@zofrex zofrex referenced this issue from a commit in zofrex/bundler
@zofrex zofrex Issue #2000 Add test for conflict markers in Gemfile.lock 336d89b
@zofrex zofrex referenced this issue from a commit in zofrex/bundler
@zofrex zofrex Issue #2000 improve error message b6cd3d0
@rohit
Collaborator

@indirect Any thoughts on this? :) Does it need any more work?

@zofrex

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 :)

@zofrex zofrex referenced this issue from a commit in zofrex/bundler
@zofrex zofrex Issue #2000 Improve test for conflict markers in lockfile 4ab3220
@indirect indirect closed this in 2a35e18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.