On Tue, Apr 23, 2013 at 2:37 PM, Matt Turner <matts...@gentoo.org> wrote: > On Tue, Apr 23, 2013 at 11:20 AM, Rich Freeman <ri...@gentoo.org> wrote: >> On Tue, Apr 23, 2013 at 2:00 PM, Jeroen Roovers <j...@gentoo.org> 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
