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