| 1 |
On Tue, Apr 23, 2013 at 2:37 PM, Matt Turner <mattst88@g.o> wrote: |
| 2 |
> On Tue, Apr 23, 2013 at 11:20 AM, Rich Freeman <rich0@g.o> wrote: |
| 3 |
>> On Tue, Apr 23, 2013 at 2:00 PM, Jeroen Roovers <jer@g.o> wrote: |
| 4 |
>>> Er, you can't be seriously suggesting we will drop repoman checks with |
| 5 |
>>> the migration to git? I don't see how that would benefit anyone. |
| 6 |
>>> |
| 7 |
>> |
| 8 |
>> Interesting point. One thing to keep in mind with git is that commits |
| 9 |
>> don't affect the "central repository." Pushes are what impacts the |
| 10 |
>> repository. |
| 11 |
>> |
| 12 |
>> If I spend six months working on a bunch of coordinated package |
| 13 |
>> changes, nobody will see a thing until I push those commits and 500 |
| 14 |
>> ebuilds all change atomically (not that I'm suggesting that lack of |
| 15 |
>> communication is to be encouraged). A repoman check on a commit may |
| 16 |
>> not reflect its impact six months later when it actually hits the main |
| 17 |
>> tree. |
| 18 |
> |
| 19 |
> ... if you're squashing 6 months of work into a single commit before pushing. |
| 20 |
> |
| 21 |
> I don't think we want to do that, do we? Maybe bisecting isn't |
| 22 |
> particularly interesting for the portage tree. |
| 23 |
|
| 24 |
I never said that I was squashing 6 months of work into a single |
| 25 |
commit, only that I was pushing 6 months worth of commits in a single |
| 26 |
operation. |
| 27 |
|
| 28 |
Any repoman checks done at the time of each commit are essentially |
| 29 |
worthless. Consider this example: |
| 30 |
|
| 31 |
1. Create app-misc/foo-1.2 which depends on app-misc/bar. Repoman |
| 32 |
checks this and it is fine. |
| 33 |
2. Do 500 other commits. |
| 34 |
3. Push it all to the tree six months later. |
| 35 |
4. Get bug report that app-misc/bar was renamed two months back. |
| 36 |
|
| 37 |
Repoman is about checking changes to the main repository. What |
| 38 |
matters isn't how the change you made impacts your clone of the |
| 39 |
repository, but how that change impacts the main repository when it |
| 40 |
eventually makes its way back. |
| 41 |
|
| 42 |
Unless your workflow is to pull, commit, and push with no intervening |
| 43 |
commits by other contributors, the repoman check needs to be done |
| 44 |
before the push, not the commit. |
| 45 |
|
| 46 |
Rich |
Archives