3 ms·
It works for SQLite because SQLite is tiny. A quick check[1] shows that they have just 1360 commits over the last year, 76% of them from just one author (and
by ajross 4y ago
It works for SQLite because SQLite is tiny. A quick check[1] shows that they have just 1360 commits over the last year, 76% of them from just one author (and just five authors total!).
You don't need complicated branch refactoring tools when you're only sharing with a handful of people. It's like working with RCS back in the day: history is still linear and no one needs to worry about cross-ports between feature branches.
[1] Ironically done using a github mirror, because those are the tools I know and they're fast.
- justin66 4y agoIt’s not true that SQLite is tiny. I don’t know what portion of the test harnesses you’re seeing in the GitHub repo you looked at, but a portion of SQLite’s tests are proprietary. [0] The size of the SQLite test code is legendary, and exceeds that of the program code by an order of magnitude. [0] https://www.sqlite.org/testing.html https://www.sqlite.org/testing.html
- the_duke 4y agoOP was clearly talking about team size and change velocity, not code size. 5 contributors, with over 70% from a single person is indeed small.
- justin66 4y agoThat’s totally fair, but insofar as the number of commits matters at all, the number sited in the grandparent post for total commits is deceptive. It’s a fraction of the number of commits that team makes.