Thanks for your all comments. Those gives me more concept of Git. I want to clarify my usage model. My daily work bases on internal project to develop features for external and internal packages both. So, I expect I have one git repo (one GIT URL) to get all required packages (internal and external), then base on it to pull the update, create patch, review patch, and push my changes for internal and external. I also hope I can use Git advantage usage for EDKII and my internal project. But, I find no obvious way to support this usage. Submodule is a little complex. Repo tool is not easy to be used in Windows. And, even if we use Repo tool, we still need to separate internal Package as single Repo, then combine them one by one into EDKII as my internal project. git filter-branch can split Package from EDKII Repo. But, this ways need script to update code. And, I am not sure whether I can base on filter-branch to push my changes. After compare them, I think submodule is the simplest way to support my usage model. So, I propose to separate Package as Repo, keep Package Repo as upstream Repo and EDKII Repo as read only. If Package Repo is read only, EDKII Repo is upstream Repo, it will bring a little burden for me. But, it is also an acceptable solution.
Last, I don't understand why GIT not smoothly supports my usage model, because it is just designed for Linux project? Thanks Liming -----Original Message----- From: Roy Franz [mailto:roy.fr...@linaro.org] Sent: Friday, June 5, 2015 12:34 AM To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] Proposal of Git Repo Layout for EDKII project On Thu, Jun 4, 2015 at 8:58 AM, Brian J. Johnson <bjohn...@sgi.com> wrote: > On 06/03/2015 08:53 PM, Jordan Justen wrote: >> Yet another idea that I've considered is trying to leverage git >> subtree. My idea was that the unified EDK II would remain the main >> upstream. >> >> I would setup an automated process to split each package off using >>git subtree, and push the separate repos. >>... >> >> I never got the time to investigate if git subtree could work as >> required, but this text from the help page seems promising: >> >> " >> split >> >> Extract a new, synthetic project history from the history of the >> <prefix> subtree. The new history includes only the commits >> (including merges) that affected <prefix>, and each of those >> commits now has the contents of <prefix> at the root of the >> project instead of in a subdirectory. Thus, the newly created >> history is suitable for export as a separate git repository. >> > > I experimented with git subtree a couple years ago for managing a > project composed of multiple sub-projects. I'm trying to remember > what I thought about it.... It works, but it tends to produce a > confusing git log, IIRC. And if you're going to push to the subtrees, > you should be careful to limit each commit to files in a single > (sub)tree. That requires developer discipline, or a good pre-commit hook. > > But for extracting packages into separate read-only repos, it should > be perfect. Note that in that mode, it's very similar (or completely > equivalent?) to "git filter-branch --subdirectory-filter". > -- > > Brian J. Johnson > If git subtree can be used to create and maintain read-only "modules" based on the single master git repo, this sounds like a good solution. This keeps the single git repo as the master, and avoids the complications of commits that cross module boundaries in the sub-module case. If git subtree can support this usage model, would read-only git subtrees for the modules meet the requirements for those who want to use "modules" individually? Note that only the upstream subtree repos are read-only, various other groups could still have internal read/write repos cloned from those, it's just that changes pushed upstream would need to go through the master git tree. If this is a generally acceptable plan, then I guess a next step is to verify that git subtree works as desired. Roy > -------------------------------------------------------------------- > > 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 ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
