| 1 |
On Fri, Jul 8, 2016 at 2:51 PM, Chí-Thanh Christopher Nguyễn |
| 2 |
<chithanh@g.o> wrote: |
| 3 |
> |
| 4 |
> I'm sorry for harping on that topic again, but if we had used grobian's |
| 5 |
> initial proposal for git migration[0] - one repository per package, and the |
| 6 |
> portage tree would be an aggregation of those - then we could have such a |
| 7 |
> thing basically for free now. |
| 8 |
|
| 9 |
Not really. Unless you planned to never delete old versions of |
| 10 |
packages from the tree. Also, if you remove a package from the tree |
| 11 |
you'd need to ensure that its repository didn't later disappear, or |
| 12 |
that people could actually find it. |
| 13 |
|
| 14 |
That design also has other problems, like a lack of consistency across |
| 15 |
the tree. If one package syncs and another one doesn't, maybe you get |
| 16 |
things that don't work. And heaven help the guy trying to do a |
| 17 |
tree-wide change. Just as with cvs there would be no association with |
| 18 |
a change in one package with a change in another. |
| 19 |
|
| 20 |
It wasn't a bad idea, but in the end the pros didn't seem worth the |
| 21 |
cons. I definitely wouldn't do it just so that I didn't have to run |
| 22 |
git log to find a deleted ebuild. |
| 23 |
|
| 24 |
-- |
| 25 |
Rich |
Archives