1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 11/08/15 12:03 PM, hasufell wrote: |
5 |
> On 08/11/2015 05:21 PM, Alexis Ballier wrote: |
6 |
>> |
7 |
>> Big changes that that go in feature branches and are merged in |
8 |
>> one pass are, from my experience, way too much prone to errors. |
9 |
>> Did anyone ever try to review a merge commit? |
10 |
>> |
11 |
> |
12 |
> You will run repoman (and probably other pkgcore based checks) |
13 |
> before you push that merge. That is for sure. |
14 |
> |
15 |
> The only problem that can arise there is that we don't roll our |
16 |
> versions via branches, but via filenames. That means you may |
17 |
> merge correctly, but in master there was already a newer version |
18 |
> of app-misc/foo which now lacks the multilib migration (which |
19 |
> isn't a tree breaker, since stuff still repomanchecks). |
20 |
> |
21 |
> We could probably come up with some magic git/bash lines that |
22 |
> help with that. As in: not just detect merge-conflicts, but also |
23 |
> "soft conflicts" in the sense that someone else touched the same |
24 |
> ebuild-directory as you in between. |
25 |
> |
26 |
> NixOS for example has (probably not only for that reason) not |
27 |
> any version based filenames, but they roll release-channels via |
28 |
> branches. |
29 |
> |
30 |
|
31 |
That sort of relates to the idea that was brought up last year, if |
32 |
portage could be made to detect and do VDB-only merges and would |
33 |
re-emerge ebuilds based on the fact that they were modified rather |
34 |
than their ${PVR} being incremented, then we could get rid of |
35 |
revision#'s entirely. Not a true version removal but it would |
36 |
reduce the number of distinct files we would be working with in |
37 |
cases like the above. |
38 |
|
39 |
But this isn't the place to discuss that tangent I don't think; that |
40 |
needs a whole new thread and a whole lot of portage development and |
41 |
possibly a PMS change? |
42 |
-----BEGIN PGP SIGNATURE----- |
43 |
Version: GnuPG v2 |
44 |
|
45 |
iF4EAREIAAYFAlXKHf0ACgkQAJxUfCtlWe23RQEAuuHF7S5bKHl8ayGYgitGZFuh |
46 |
ETcKKDxaKw76i2pVDwkA/RLwUKUpbZpId7mvl3j9c4obO9ZAxCaxW25UikU1ZtsV |
47 |
=YBDy |
48 |
-----END PGP SIGNATURE----- |