-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 23/04/13 03:11 PM, Rich Freeman wrote: > On Tue, Apr 23, 2013 at 2:37 PM, Matt Turner <[email protected]> > wrote: >> On Tue, Apr 23, 2013 at 11:20 AM, Rich Freeman <[email protected]> >> wrote: >>> On Tue, Apr 23, 2013 at 2:00 PM, Jeroen Roovers >>> <[email protected]> wrote: >>>> Er, you can't be seriously suggesting we will drop repoman >>>> checks with the migration to git? I don't see how that would >>>> benefit anyone. >>>> >>> >>> Interesting point. One thing to keep in mind with git is that >>> commits don't affect the "central repository." Pushes are what >>> impacts the repository. >>> >>> If I spend six months working on a bunch of coordinated >>> package changes, nobody will see a thing until I push those >>> commits and 500 ebuilds all change atomically (not that I'm >>> suggesting that lack of communication is to be encouraged). A >>> repoman check on a commit may not reflect its impact six months >>> later when it actually hits the main tree. >> >> ... if you're squashing 6 months of work into a single commit >> before pushing. >> >> I don't think we want to do that, do we? Maybe bisecting isn't >> particularly interesting for the portage tree. > > I never said that I was squashing 6 months of work into a single > commit, only that I was pushing 6 months worth of commits in a > single operation. > > Any repoman checks done at the time of each commit are essentially > worthless. Consider this example: > > 1. Create app-misc/foo-1.2 which depends on app-misc/bar. > Repoman checks this and it is fine. 2. Do 500 other commits. 3. > Push it all to the tree six months later. 4. Get bug report that > app-misc/bar was renamed two months back. > > Repoman is about checking changes to the main repository. What > matters isn't how the change you made impacts your clone of the > repository, but how that change impacts the main repository when > it eventually makes its way back. > > Unless your workflow is to pull, commit, and push with no > intervening commits by other contributors, the repoman check needs > to be done before the push, not the commit. > > Rich >
This makes a lot of sense to me too -- repoman checks that are absolutely -needed- are those run at push time, specifically when pushing to master. 'git commit' time doesn't have an equivalent in cvs, but to me the checks that should be done at this time would be covered by the 'repoman -d full' checks we're already supposed to do, and I don't think those need to be enforced. Alternatively, we could enforce repoman checks on any commit or push operation in master, and leave branches to their own devices. Of course, I haven't seen (or looked for, tbh) how tree development will be implemented/suggested to be done in git so I've no idea what role branches might play.. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlF24C0ACgkQ2ugaI38ACPASUQD/VqYe+f28wPGByWjcCicWiF5e 84vjyyrMxS3IF1qLeisA/jzfePn7pID8RsUqLYUtdSF+xo6dZDhLJgQARelS4yMx =bywE -----END PGP SIGNATURE-----
