Re: [gentoo-dev] Revision bumps vs git commits atomicity

[Kent Fredric]

On Sat, 3 Dec 2016 15:06:36 +0000
Markos Chandras <hwoarang@g.o> 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.