I will mention that any solution short of sucking in the third party dependencies into the main repo (not as a submodule) -- which no one wants to do anyway -- will be slightly awkward to git bisect. Not impossible; the pain is about the same for both main options:
a) in theory git-bisect should adjust submodules to the correct hash. in practice you need to run `git submodule update` after every step in order to check out the appropriate submodule commits. b) similarly, for composer you need to run a command to update the 3rd party packages, if any dependencies have changed. (for node.js projects, which have similar issues, you need to run `npm install` after every step. For regressions that are easily found by running a test suite, you can arrange for `git bisect run` to do the appropriate git, composer, or npm command before running the test. So, it's somewhat awkward, but manageable. And usually the 3rd-party dependencies don't typically change as often as the core code, so this doesn't come up all that often. Two main benefits of `git submodule`: (1) perhaps one day `git bisect` and `git submodule` will play nicer together; (2) since references are to a git hash, crawling through history is repeatable. One disadvantages: (1) because git allows `.gitmodules` to differ from your local set of module repo sources (in `.git/config`), it is rather too easy to forget to push a submodule commit referenced from the main repo -- although hopefully jenkins will catch errors of this sort, The main disadvantage of using `composer`/`npm`/etc directly is that you are at the mercy of the upstream package repo to behave well. That is, if the upstream repo allows uploaders to change the tarball associated with version X.Y.Z, you may find it hard to reproduce past configurations. Similarly, if you specify loose package version constraints, you are at the mercy of the upstream maintainers to actually maintain compatibility between minor versions or what-have-you. Parsoid and some other WMF projects actually use a hybrid approach where we use `npm` and not submodules, but we maintain a separate "deploy" repo which combines the main code base (as a submodule) and specific versions of the third party code. --scott _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
