Could content hash be a map of hashes instead of a single string? #12541
Closed
SpencerMalone
started this conversation in
General
Replies: 1 comment
-
It might reduce the amount of conflicts yes you're right in that. BUT the problem is we do want this to conflict if two different things affecting package resolutions changed, even if seemingly unrelated. Because if you change in different PRs two requirements of two packages that both end up requiring a third package C, maybe you could then merge the lock files just fine, but you might end up with a version of C that actually does not satisfy the requirements anymore, or things like this. So IMO the best is to replay composer updates whenever you get a conflict, to ensure you get a lock file that is correct. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
By far, the largest thing I get merge conflicts on with composer is the content hash, which as far as I can tell from
composer/src/Composer/Package/Locker.php
Lines 91 to 118 in c311f1f
?
If there was a "real" conflict during resolution, like package A installed package C at 1.0, and package B installed package C at 2.0, wouldn't those just show up as "real" merge conflicts in the packages map of the composer.lock?
Beta Was this translation helpful? Give feedback.
All reactions