On Wed, Jun 3, 2015 at 7:50 AM, Brian J. Johnson <bjohn...@sgi.com> wrote: > On 06/03/2015 04:50 AM, Gao, Liming wrote: >> Hi, all >> >> Now, EDKII project Git mirror is ready in GitHub (https:// >> <https://github.com/tianocore>github.com/tianocore >> <https://github.com/tianocore>). There are EDKII project Repo and each >> package Repo. After migrate EDKII from SVN to GitHub, EDKII Git Repo >> will be writable, EDKII SVN project will become mirror. I expect to keep >> write access in the centralized Git repo. But, EDKII project Repo (edk2) >> and MdePkg Repo (edk2-MdePkg) includes the same source code. So, only >> one of them will be writable. My proposal is to make Package Repo be >> Read & Write, and update EDKII project to link each package by submodule >> way. The benefit of this way is: >> >> 1.EDKII project is too big. After separate them, the developers can just >> pull their used packages instead of full. >> >> 2.The different packages have the different owners. After separate them, >> the package owner can give write access for the different developers. >> >> 3.Close source project can refer to EDKII packages. Those project can be >> easily setup by git submodule. >> >> Compared to EDKII project Repo, submodule EDKII project Repo just >> includes edksetup.bat, and edksetup.sh. Some BKM of submodule is shared >> here. >> >> 1.Every Git operation is took for Package Repo. Pull, Branch, Commit, >> Create Patch, Fork, and Pull Request are all for Package Repo. If your >> patch changes multiple packages, you need to commit and create patch per >> Package. >> >> 2.git submodule foreach “command” can be used to run command on every >> package, for example git submodule foreach "git pull" >> > > 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....
Agreed, please no submodules. I eagerly went to the github page, and was shocked to see 3 pages of submodules. I have to work with some projects that use submodules, and they are a huge pain. They technically "work", but should be a last resort (ie composing a larger project from existing, separately developed projects that are already managed in git.) EDK2 should be a single git repository. I very strongly think the submodule plan is a very bad idea. Thanks, Roy > > Thanks, > -- > > Brian J. Johnson > > -------------------------------------------------------------------- > > My statements are my own, are not authorized by SGI, and do not > necessarily represent SGI’s positions. > > ------------------------------------------------------------------------------ > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
