On 06/03/15 22:00, Jordan Justen wrote: > On 2015-06-03 12:01:58, Andrew Fish wrote: >> On Jun 3, 2015, at 7:50 AM, Brian J. Johnson <bjohn...@sgi.com> wrote: >>> I fully agree with others' reluctance to use git submodules, and the >>> reasons they have expressed: git submodules are a major pain for >>> developers, and the concerns Liming listed above can be addressed in >>> other ways. >>> >>> When my internal team first transitioned to git, we set up a complex >>> submodule-like system to (theoretically) allow easily updating common >>> code among different projects. That only lasted a month or two: having >>> to manage multiple repositories for day-to-day work, and the lack of a >>> single commit history spanning the entire tree doomed that scheme. >>> >>> I collapsed everything together into a single repo using some git >>> filter-branch magic, and we've been happy ever since. >>> >>> Please, no submodules…. >> >> I agree that submodules add complexity, and make things harder. >> Maybe for hardware project they are OK, but the core of edk2 should >> be one project. > > I also would prefer if EDK II upstream could be a single repo, but I > understand why there is also a desire to consider submodules. > > First and foremost, inside Intel, the svn:externals feature is used > extensively to compose platform trees together. And, submodules map > very closely to that usage model. > > But, even if you try to consider alternatives to submodules for > composing platform trees, things get complicated. > > One idea, is to fork the EDK II master tree, and add submodules for > your platform specific modules. To me this ends up with the worst of > both worlds. 1. All git commands are difficult to use tree-wide, as > expressed in this thread, and 2. You don't have the power to select > only the EDK II modules that you need for your platform.
True. I think git's history / background can help us find an explanation for questions like the one above. (Note, I'm not saying "find satisfying answers / solutions", just "an explanation".) Git was invented for facilitating the Linux kernel's development. (Hence, when in doubt, look to Linux.) Indeed, when you clone the Linux repo, you get everything. > Another idea is to fork the EDK II master tree and add your platform > specific modules directly into the fork. In this case, you can still > use all the git commands, but you once again can't select only the EDK > II modules that you need for your platform. Agreed. (Similarly, when you clone or pull the kernel, you get driver directories you might never enter or build.) > Other difficulties arise, > such as, what if you have a chipset package that you want to share for > multiple platforms? Unless all the platforms for that chipset live in > the same branch, how do you easily share common code for those chipset > packages? (Maybe a separate 'upstream' for the chipset code that the > platforms merge in as needed?) Exactly. This is what would follow the Linux development model. The central chipset package would have a maintainer, a team, a mailing list (perhaps :)). The chipset package maintainer would apply patches in his own tree, and sometimes send pull requests to the "central" repository's "chief maintainer". After a pull (when the chipset update would appear at once in the central master branch, but without losing history), platform teams could fetch that branch, and either rebase their development branches on top, or merge the updated master into their development branches. > I think Android might share some of the same concerns, and their > solution was to invent a submodules-like alternative called 'repo' > that layers on git. I thought of symlinks (and I was surprised to see in Garrett's email that Google's "repo" operates with symlinks!), but, as Garrett describes, symlinks don't really work on windows. (Again, git was invented for Linux, on Linux...) > So, can we add these concerns into the discussion, and maybe document > an alternative way to address these concerns if submodules aren't > used? Would it be possible to maintain the submodules in-house only? If the "upstream first" principle is followed -- that is, everything that gets open sourced gets *developed* for upstream in the first place -- then it should be possible to port the upstream patches to the internal submodules. Is that correct? Package owners can keep an eye on upstream patches (in reviews) and intervene if a patch were to introduce too tight coupling between packages. (This is being watched already, and Intel's in-house model can apparently deal with the currently existing interdependencies.) Once the upstream patches / history have been dispersed (backported, or branch-filtered) to the in-house submodules, the current usage / platform build model could continue. Red Hat follows the "upstream first" model, and we do a lot of backports. (No submodules though, as far as kernel & virt are concerned.) ... It's hard to find a common workflow; the requirements and the means of coordination are different. Thanks Laszlo ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
