On Sat, 3 Dec 2016 15:06:36 +0000 Markos Chandras <hwoar...@gentoo.org> wrote:
> That's reasonable but I also think that bumping and fixing an ebuild at > the same time can be considered an atomic change since it's effectively > a _new_ ebuild One problem is that can seriously confuse git about what's happening, given how similar our ebuilds are, and given gits only mechanism for determining "rename" is + filename/a 0xSHA1 - filename/b 0xSHA1 If "filename/a" is sufficiently different from "filename/b" and close enough to some other non-target "filename/c", it could retroactively be confused into thinking this happened. copy filename/c -> filename/a (98%) remove filename/b And then you go and rebase that somewhere were filename/c was actually modified, and filename/b was modified, and you end up with merge conflicts where git propagates changes from filename/c to filename/a and then makes you battle with "modified filename/b vs removed filename/b" This is why I prefer to take the approach of: 1. Fix everything first. 2. -r1 bump in a dedicated (or commits) at the end. Then git tends to be smarter about things, and realises the change in the ebuild was applied to a moved file, and attempts to modify the moved file instead, and the only headaches are the -r bumps themselves, and git itself is *usually* more disposed to getting these right. But uh. Don't look at what github likes to do: https://github.com/gentoo/gentoo/pull/2956/commits/52da7b3a525ff1c4f4e1ad73fe9e0ab91cf6e799 ..rl-JSON-PP/perl-JSON-PP-2.273.0-r3.ebuild → ...ive-Tar/perl-Archive-Tar-2.40.0-r4.ebuild ..ocale-Maketext-Simple-0.210.100_rc.ebuild → ...ar/perl-Archive-Tar-2.40.100_rc-r1.ebuild ..ive-Tar/perl-Archive-Tar-2.40.0-r3.ebuild → ...rl-JSON-PP/perl-JSON-PP-2.273.0-r4.ebuild ..e-Tar/perl-Archive-Tar-2.40.100_rc.ebuild → ...le-Maketext-Simple-0.210.100_rc-r1.ebuild Its totally understandable why it gets confused: md5sum perl-Archive-Tar/perl-Archive-Tar-2.40.0-r4.ebuild \ perl-Archive-Tar/perl-Archive-Tar-2.40.100_rc-r1.ebuild \ perl-JSON-PP/perl-JSON-PP-2.273.0-r4.ebuild \ perl-Locale-Maketext-Simple/perl-Locale-Maketext-Simple-0.210.100_rc-r1.ebuild 1fe782df38a2c2cc01615012b9915da9 perl-Archive-Tar/perl-Archive-Tar-2.40.0-r4.ebuild 5102f6ac13ac331465c64258d8f413c5 perl-Archive-Tar/perl-Archive-Tar-2.40.100_rc-r1.ebuild 1fe782df38a2c2cc01615012b9915da9 perl-JSON-PP/perl-JSON-PP-2.273.0-r4.ebuild 5102f6ac13ac331465c64258d8f413c5 perl-Locale-Maketext-Simple/perl-Locale-Maketext-Simple-0.210.100_rc-r1.ebuild Rationale: most users are working from rsync. So for them, the -r step is mostly a "propagate this change" mechansim. These users are unlikely to see the intermediate stage where you modified the file before the -r bump, because the -r bump was pushed atomically with the rest. People who clone from git are also not typically "winding back" the head, and so they'll get their -r bumps atomically with the changes when they pull. People who *are* winding back the head are likely winding back to a specific moment in the history: 1. If they're winding back to before your commit series, then it doesn't matter 2. If they're winding back to after your commit series, then they have the needed -r bump 3. If they're winding back to some point within the commit series, things may be a little hairy. ( and maybe this is where the "-r bump first" strategy is more useful? ) But then it depends what they're rewinding *For* (prebumping) If they were trying to avoid the change you made after you -r bumped, rewinding to before the change won't trip portage updates. (postbumping) If they were meaning to include the change you made before you -r bumped, rewinding to after the change won't trip portage updates. It seems in either case, post/pre bumping to within the change set will have an edge case somewhere where a user has to be assumed to explicitly tell portage to reinstall the target package instead of relying on -r bumps to propagate it.
pgpDOM2vPVkCC.pgp
Description: OpenPGP digital signature
