On Tue, 11 Aug 2015 18:03:54 +0200 hasufell <hasuf...@gentoo.org> wrote:
> 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. passing repoman, or any static checker, is definitely a very small subset of what is needed to be good for gentoo-x86 > 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. After fixing all these sorts of conflicts, I hope you test things thouroughly, again, after the merge. In the end, it's shorter and simpler to stop and think at the beginning on how to split your work in small commits without branching.
