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: > > 1. Download size for people wanting to submit new logs. > Can be solved with shallow git clones of the board-status repository. > > 2. 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. > > 3. 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 > -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
