Hi Martin,
thanks - that's a great idea. While we are touching submodules
anyway - can we make the path a bit more agnostic? While forking
coreboot into my org I found that I either:
1. Have to clone all submodules as well
2. or touch the submodules file to point to the upstream coreboot
repo e.g. instead of '../flashrom.git' use
'../../coreboot/flashrom.git'. That works on github and should
also work within our upstream coreboot repo.
Maybe I am using git submodules wrong here.. :)
Best,
Chris
Hi Martin, sounds like a really good idea! On 21.01.24 05:16, Martin Roth via coreboot wrote:Here's a spreadsheet with the submodule size data, along for recommendations for each. https://docs.google.com/spreadsheets/d/1DAnFFnoLxdLE15CsUTE_AuCZeKG-UdrBndiFxhPDEO8/edit <https://docs.google.com/spreadsheets/d/1DAnFFnoLxdLE15CsUTE_AuCZeKG-UdrBndiFxhPDEO8/edit?usp=sharing> Submodules recommended to use --depth=1 are: arm-trusted-firmware, intel-sec-tools, stm, chromeec, blobs, fsp, vbootNot sure if we actually need to make a distinction. Most people probably won't look into the submodules anyway. Your selection seems fine to me, though.All other submodules would fetch the current branch. My thought is that we set the default for each submodule to the recommended value in the sheet, then we can add a Make target or Kconfig option that pulls down the rest, for anyone who wants the full data.Most people who edit submodules probably know Git well enough. So I would only invest into the Kconfig/Makefile logic if people request it. Cheers, Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
