On Thu, Sep 27 2018, 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. > > In working with the Android source files, you use Repo for > across-network operations. For example, with a single Repo command you > can download files from multiple repositories into your local working > directory. > > In most situations, you can use Git instead of Repo, or mix Repo and > Git commands to form complex commands. > > [1] https://source.android.com/setup/develop/ Some questions just out of curiosity, not for this patch in particular: Those docs seem to describe the situation without this patch, with this patch is the repo tool fully replaced? How are you planning to migrate from repo to this on a repository-data basis, does gerrit also populate .gitmodules files appropriately, which your clone --recurse-submodules will pick up, but repo will just ignore, so you can use the two in parallel? Now "repo init -u" takes a URL to a manifest of repositories to stitch together, I've understood from past conversations (but am not sure) that this is used e.g. by downstream Android vendors so they can use what Google's using + whatever they have in-house, i.e. make the manifest the set of open source repos plus some (e.g. drivers specific to their device). How is that sort of workflow going to work where you (presumably) have do that via .gitmodules + commit entries in trees? They run their own Gerrit install with some magic to sync back & forth? I assume that now the recursive "checkout" relies on all the origin/HEAD symbolic refs pointing to "master", but how is this going to deal with incorporating a repo whose main branch has a different name? E.g. "trunk" or "blead"? Perhaps some interaction with checkout.defaultRemote + submodule.<name>.branch=<NAME> could make "git checkout :mainbranch" DWYM. > * Fetching changes ("repo sync") needs to fetch all repositories, as there > is no central place that tracks what has changed. In a superproject > git fetch can determine which submodules need fetching. In Androids > case the daily change is only in a few repositories (think 10s), so > migrating to a superproject would save an order of magnitude in fetch > traffic for daily updates of developers. Interesting that in all this time with the reliance on a central server repo wasn't already asking some custom API "what repos changed since xyz time" to narrow that down, but hey, .gitmodules + commit entries in trees will do it for you. > * Sometimes when the dependencies are not on a clear repository boundary > one would like to have git-bisect available across the different > repositories, which repo cannot provide due to its design. I assume that you're not upgrading independently to e.g. every single linux commit, just stable releases, so does bisecting deal with knowing that e.g. a breakage occurred when linux.git was updated from v4.10 to v4.12, and then to go within the repo itself and bisect from there, or is that done manually?
