> On 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….
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’ll also point out that `git grep` only works in the submodule. Actually git
in general only works from inside the submodule.
For example if you have a bunch of submodules and you do
git status
all you will see is:
modified: MdePkg (modified content, untracked content)
modified: MdeModulePkg (modified content, untracked content)
To see the change lists you need to cd into the directory of the submodule and
run git status.
Thanks,
Andrew Fish
>
> 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
