Ard: Subtree model requires to be kept in sync by automation. And, Subtree Repo is still not upstream repo. Developer is required to move his change to upstream repo and push it.
Yes. We can have multiple Repos like you. EDKII, SctPkg, InternalPkgs. Developer needs to manually combine them together. For example, to build SctPkg, you need EDKII Pkg. If you use submodule to link EDKII, you require single package Repo. I am thinking another solution. Could I merge EDKII Repo and SctPkg Repo in my local? If so, I will have the full code bases. Thanks Liming -----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Wednesday, June 17, 2015 1:53 AM To: edk2-devel@lists.sourceforge.net; Gao, Liming Subject: Re: [edk2] Proposal of Git Repo Layout for EDKII project On 16 June 2015 at 19:39, Olivier Martin <olivier.mar...@arm.com> wrote: > Most EDK2 users uses MS Windows host machine & GUI tool. I am not sure 'git > subtree' that is not part of the default git tool fits with the EDK2 > community requirements. > That may be true, but the suggestion is not for every user to use git subtree individually, but to maintain a number of subtree mirrors that are kept in sync by automation. That way, you can compose your own workspace with various EDK2 packages as before. The only unsolved issue is how to convert your patches against those subtrees into patches that can be applied to the core upstream version. > Having a main/unique EDK2 repository is not incompatible with the inclusion > of third-party/private components in your development environment. > In my working tree, I have: > - EDK2 as a git repository > - SctPkg as a git repository > - Some private platforms as separate git repository If really you want > to get a set of EDK2 and third-party/private components nothing prevent you > to create a branch based on 'master' that would add your external components > as git submodules. > Perhaps Liming can comment on whether or not his use case is comparable? > -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: 08 June 2015 10:09 > To: edk2-devel@lists.sourceforge.net > Subject: Re: [edk2] Proposal of Git Repo Layout for EDKII project > > On 5 June 2015 at 18:59, Gao, Liming <liming....@intel.com> wrote: >> 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. >> > > Git submodules may be the simplest way to support /your/ particular use case, > but I think the pushback in this thread against it comes mostly from people > who have actually used git submodules, so I suggest we take those comments > seriously. > > It seems that you are already in the situation where you need to push your > changes to multiple repositories at the same time, and those repositories are > not tightly coupled. I don't think this applies to many of us, so it doesn't > seem fair to me to force others to adopt that mode of development while not > strictly necessary. > > I think the subtree approach is reasonable, where we have a single read-write > core EDK2 repo (probably just the existing one at GitHub) and use some > automation to keep a collection of subtree mirrors in sync. As Roy has > confirmed, git subtree is repeatable, i.e., it produces the exact same commit > IDs when invoked several times, so the subtree repositories would be stable > as well. > > For submitting your patches, note that git format-patch supports src-prefix > and dst-prefix options, which perhaps we may use to convert your subtree > patches to core patches? I haven't tried it myself but it looks promising. > >> Last, I don't understand why GIT not smoothly supports my usage model, >> because it is just designed for Linux project? >> > > Git was obviously not designed for maintaining a mix of open and closed > source software. Mind you, I don't think there is anything wrong with that, > it just wasn't on any of the Git developers' radar. > > -- > Ard. > > > >> -----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 > > ---------------------------------------------------------------------- > -------- _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2557590 ARM Holdings plc, > Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in > England & Wales, Company No: 2548782 > ---------------------------------------------------------------------- > -------- _______________________________________________ > 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
