Maybe using git a monotonically increasing entry count is the wrong way to go about it. That's beyond the scope, mission, design and goal of git.
I would rethink the entire board-status mechanism to something more suited to the task than git.
Yours truly, The Devil
On 02/17/2016 01:07 PM, Carl-Daniel Hailfinger wrote:
Hi,
since various automated systems started submitting board status files, the board-status repository has grown significantly to a point where submitting a new board from scratch requires a download which is bigger than the whole coreboot repository. Once I hook up four more systems in my lab, I expect this growth to accelerate quite a bit. It will get even more extreme once I start testing every commit instead of limiting the tests to one per hour.
This poses three problems:
- Download size for people wanting to submit new logs.
Can be solved with shallow git clones of the board-status repository.
- Download size for people wanting to find out where some breakage
happened. Not really solvable unless we commit less reports, and that makes bisection harder.
- Server load for anything working with the board-status repo.
This means gitweb and the wiki, and that's not a problem (yet).
Should we just ignore the size until it becomes too large, is size not a problem or should we immediately do something?
Regards, Carl-Daniel