| 1 |
On Tue, 11 Aug 2015 18:03:54 +0200 |
| 2 |
hasufell <hasufell@g.o> wrote: |
| 3 |
|
| 4 |
> On 08/11/2015 05:21 PM, Alexis Ballier wrote: |
| 5 |
> > |
| 6 |
> > Big changes that that go in feature branches and are merged in one |
| 7 |
> > pass are, from my experience, way too much prone to errors. Did |
| 8 |
> > anyone ever try to review a merge commit? |
| 9 |
> > |
| 10 |
> |
| 11 |
> You will run repoman (and probably other pkgcore based checks) before |
| 12 |
> you push that merge. That is for sure. |
| 13 |
|
| 14 |
|
| 15 |
passing repoman, or any static checker, is definitely a very small |
| 16 |
subset of what is needed to be good for gentoo-x86 |
| 17 |
|
| 18 |
> The only problem that can arise there is that we don't roll our |
| 19 |
> versions via branches, but via filenames. That means you may merge |
| 20 |
> correctly, but in master there was already a newer version of |
| 21 |
> app-misc/foo which now lacks the multilib migration (which isn't a |
| 22 |
> tree breaker, since stuff still repomanchecks). |
| 23 |
> |
| 24 |
> We could probably come up with some magic git/bash lines that help |
| 25 |
> with that. As in: not just detect merge-conflicts, but also "soft |
| 26 |
> conflicts" in the sense that someone else touched the same |
| 27 |
> ebuild-directory as you in between. |
| 28 |
> |
| 29 |
> NixOS for example has (probably not only for that reason) not any |
| 30 |
> version based filenames, but they roll release-channels via branches. |
| 31 |
|
| 32 |
After fixing all these sorts of conflicts, I hope you test things |
| 33 |
thouroughly, again, after the merge. In the end, it's shorter and |
| 34 |
simpler to stop and think at the beginning on how to split your work in |
| 35 |
small commits without branching. |
Archives