Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > (dropping cc-s to my internal address that I don't use on this list > and to git-core@xxxxxxxxxx which bounces) > Hi, > > Stefan Beller wrote: > >> Internally we have rolled out this as an experiment for >> "submodules replacing the repo tool[1]". The repo tool is described as: >> >> Repo unifies Git repositories when necessary, performs uploads to the >> Gerrit revision control system, and automates parts of the Android >> development workflow. Repo is not meant to replace Git, only to make >> it easier to work with Git in the context of Android. The repo command >> is an executable Python script that you can put anywhere in your path. > [...] >> Submodules can also be understood as unifying Git repositories, even more, >> in the superproject the submodules have relationships between their >> versions, which the repo tool only provides in releases. >> >> The repo tool does not provide these relationships between versions, but >> all the repositories (in case of Android think of ~1000 git repositories) >> are put in their place without depending on each other. >> >> This comes with a couple of advantages and disadvantages: > > Thanks for describing this background. Thanks for this. I probably won't be reading this before other topics, but I've often found that changes from google were lacking the backstory to make sense of them as a coherent whole. For example, a patch that says "Instead of detaching at the commit recorded in the superproject, check out the branch with the same name, even if it points at a different commit. Here is the write up of what it does in the Documentation/ and code" is hard to judge beyond checking if the code does what it claims to do and if the docs describe what the code does---without backstory like this that talks about how individual small pieces fit within the plan for the whole thing, judging if that "what it claims to do" is even sensible is impossible.
