1 |
On Tue, Apr 23, 2013 at 2:00 PM, Jeroen Roovers <jer@g.o> wrote: |
2 |
> Er, you can't be seriously suggesting we will drop repoman checks with |
3 |
> the migration to git? I don't see how that would benefit anyone. |
4 |
> |
5 |
|
6 |
Interesting point. One thing to keep in mind with git is that commits |
7 |
don't affect the "central repository." Pushes are what impacts the |
8 |
repository. |
9 |
|
10 |
If I spend six months working on a bunch of coordinated package |
11 |
changes, nobody will see a thing until I push those commits and 500 |
12 |
ebuilds all change atomically (not that I'm suggesting that lack of |
13 |
communication is to be encouraged). A repoman check on a commit may |
14 |
not reflect its impact six months later when it actually hits the main |
15 |
tree. |
16 |
|
17 |
The right time to run repoman is probably right before doing a push, |
18 |
regardless of when any git commits were made. That isn't to say that |
19 |
it can't be run sooner. |
20 |
|
21 |
So, splitting something up into multiple commits can be very |
22 |
lightweight, if repoman is only run before the push. This might |
23 |
create a need to be able to run repoman on more than one package |
24 |
directory, but on less than the entire tree (otherwise you'll end up |
25 |
having to do another pull/rebase before you push anyway). |
26 |
|
27 |
Rich |