Abort when lock contains failed git merge #2000

Closed
indirect opened this Issue Jun 22, 2012 · 8 comments

Projects

None yet

3 participants

@indirect
Member

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
zofrex commented Jun 29, 2012

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
Member

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
zofrex commented Jun 29, 2012

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
Member

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
zofrex commented Jun 29, 2012

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
Member

That would be awesome. :)

On Jun 29, 2012, at 12:15 PM, zofrex wrote:

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


Reply to this email directly or view it on GitHub:
#2000 (comment)

@zofrex zofrex added a commit to zofrex/bundler that referenced this issue Jun 29, 2012
@zofrex zofrex Issue #2000 Add test for conflict markers in Gemfile.lock 336d89b
@zofrex zofrex added a commit to zofrex/bundler that referenced this issue Jul 9, 2012
@zofrex zofrex Issue #2000 improve error message b6cd3d0
@rohit
Collaborator
rohit commented Nov 8, 2012

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

@zofrex
zofrex commented Nov 8, 2012

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 added a commit to zofrex/bundler that referenced this issue Nov 11, 2012
@zofrex zofrex Issue #2000 Improve test for conflict markers in lockfile 4ab3220
@indirect indirect closed this in 2a35e18 Feb 17, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment