> On May 26, 2016, at 11:14 PM, Robin Sommer <ro...@icir.org> wrote: > >> Is it an important use case for the client to be able to interact w/ >> other repos that are structured like the one the Bro Team will be >> hosting? Seems less likely that people will want to do that >> especially if the CBAN repository is easy enough for people to submit > > Yeah, agree it's less important with that liberal model. I would still > like to support it though unless it's a major pain.
Ok, I’ll plan from the beginning to be able point to multiple CBAN-like repository structures and then complain if I find out it’s complicated to support that. >> The client's “update” command will do a “git pull” in the parent repo >> and then a “git fetch” in any installed submodules. > > So does that mean the client ignores the version that the central CBAN > parent repository points to? Say Seth finished version 1.0 of his > cool-plugin and files a merge request. We add the submodule to CBAN; > it will point to 1.0. Then Seth updates to 1.1 on his end. CBAN would > still point to 1.0, but clients would just move their local clones to > 1.1, ignoring the parent repository's state. Is that what you have in > mind? Yeah, the parent repo would always point to the first version that was submitted, but when a user chooses to install something, that submodule gets initialized/cloned and the user can choose to use whatever version of it they want. And it won’t be the common case for a user to be doing any actual work inside the parent repo (unless they’re working on the cban client code), so it shouldn’t be a big deal if things like `git status` in the parent repo show a bunch of the “new commits” messages for each installed submodule. But I’ll also probably structure it so all submodules get cloned in to a subdirectory and then list that subdirectory in .gitignore to limit the noise. - Jon _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
