On Wed, Jun 3, 2015 at 1:00 PM, Jordan Justen <jordan.l.jus...@intel.com> 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. > > 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. 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?) > > 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. > > So, can we add these concerns into the discussion, and maybe document > an alternative way to address these concerns if submodules aren't > used? > > Thanks, > > -Jordan >
I'm wondering how this all works with the single upstream SVN repository we have now? Are people routinely checking out subdirectories of the repository, and including these in their internal repositories? If this is a key usage model it is going to be difficult to replicate this with git. Honestly if the choice comes down to an EDK2 upstream being git with 40 submodules, or a single SVN repository (with a git mirror), I'd rather have the single SVN repository. I'd never use SVN, but just use the git mirror. The maintainers would would still need to use SVN, but that's not my problem :):) The people that want to use SVN could use SVN, and those that want to use git (except for maintainers/committers :) could use git. Roy ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
