On 08/11/2015 05:21 PM, Alexis Ballier wrote: > > Big changes that that go in feature branches and are merged in one pass > are, from my experience, way too much prone to errors. Did anyone ever > try to review a merge commit? >
You will run repoman (and probably other pkgcore based checks) before you push that merge. That is for sure. The only problem that can arise there is that we don't roll our versions via branches, but via filenames. That means you may merge correctly, but in master there was already a newer version of app-misc/foo which now lacks the multilib migration (which isn't a tree breaker, since stuff still repomanchecks). We could probably come up with some magic git/bash lines that help with that. As in: not just detect merge-conflicts, but also "soft conflicts" in the sense that someone else touched the same ebuild-directory as you in between. NixOS for example has (probably not only for that reason) not any version based filenames, but they roll release-channels via branches.
