-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 11/08/15 12:03 PM, hasufell 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.
>
> 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.
>
That sort of relates to the idea that was brought up last year, if
portage could be made to detect and do VDB-only merges and would
re-emerge ebuilds based on the fact that they were modified rather
than their ${PVR} being incremented, then we could get rid of
revision#'s entirely. Not a true version removal but it would
reduce the number of distinct files we would be working with in
cases like the above.
But this isn't the place to discuss that tangent I don't think; that
needs a whole new thread and a whole lot of portage development and
possibly a PMS change?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iF4EAREIAAYFAlXKHf0ACgkQAJxUfCtlWe23RQEAuuHF7S5bKHl8ayGYgitGZFuh
ETcKKDxaKw76i2pVDwkA/RLwUKUpbZpId7mvl3j9c4obO9ZAxCaxW25UikU1ZtsV
=YBDy
-----END PGP SIGNATURE-----
