Composer Merge Conflict Resolution When Upgrading Symfony2 Standard Edition

Question

My project is based on the version of Symfony Standard Edition that I cloned from the Symfony SE source repository . Of course, Symfony distributes its own composer.json and composer.lock files, noting its dependencies.

I use the master branch for my project development, and since starting the project added my own project dependencies to composer.json and blocked them with composer.lock .

But now it's time to update my project to use Symfony SE 2.1.3.

I have a Symfony Standard Edition repository added as a remote git:

 git remote add symfonyse git://github.com/symfony/symfony-standard.git 

And I can merge the latest changes in the symfonyse repository 2.1 branch to get the latest version 2.1:

 git pull symfonyse 2.1 

Of course, you may encounter merge conflicts because I changed composer.json with my own dependencies, and composer.lock previously locked for my old dependencies.

But composer.lock now in conflict trying to combine the latest Symfony2 SE locks into my project-dependent dependencies (including my depils and Symfony 2.1.0 deps). Manual merging would be very tiring!

What is the best way to resolve these conflicts in composer.lock ?

Should I ignore merge conflicts in composer.lock by doing a git checkout -- composer.lock , which returns composer.lock back to its contents before initiating the merge? I believe that I could run composer update for every dependency Symfony2 SE requires it to be updated in the new composer.json changes that I just merged.

Or should I accept all the changes that were combined with composer.lock , commit them, and then just update all my project dependencies by running composer update ? This would essentially create a new lock file anyway with locks for Symfony 2.1.3 and my dependencies. I'm just not sure if I need updated updates for the lock file if I also get the latest composer.json changes.

Answer 1

I would say that the best / ideal case is if you have several stable requirements (not a complete dev-master ..), then you can just rm composer.lock (or git checkout) and run the update to make sure that you get recent dependencies on everything.

If this is not possible, you can also simply undo the changes from the upstream and composer update <specific packages> to bring them up to speed. This, however, is error prone and tedious, so I think it's best to make sure that you have sufficiently strong dependencies in your project so that you can update the composer without any problems.