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.
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. -----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
