On 17 June 2015 at 14:21, Gao, Liming <liming....@intel.com> wrote: > 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. >
Indeed. Btw you never responded to my question below: >> 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. >> > 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. > > -----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
