On 06/04/15 03:53, Jordan Justen wrote: > On 2015-06-03 13:00:30, Jordan Justen wrote: >> But, even if you try to consider alternatives to submodules for >> composing platform trees, things get complicated. >> >> One idea, is to fork the EDK II master tree, and add submodules for >> your platform specific modules. To me this ends up with the worst of >> both worlds. 1. All git commands are difficult to use tree-wide, as >> expressed in this thread, and 2. You don't have the power to select >> only the EDK II modules that you need for your platform. >> >> Another idea is to fork the EDK II master tree and add your platform >> specific modules directly into the fork. In this case, you can still >> use all the git commands, but you once again can't select only the EDK >> II modules that you need for your platform. Other difficulties arise, >> such as, what if you have a chipset package that you want to share for >> multiple platforms? Unless all the platforms for that chipset live in >> the same branch, how do you easily share common code for those chipset >> packages? (Maybe a separate 'upstream' for the chipset code that the >> platforms merge in as needed?) > > 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. > > So, people who like the idea of git submodules can use them.
Sounds promising. > The main > disadvantage to them would be to get things upstream, they'd have to > convert their commits to the merged unified tree. I think the conversion (= porting) should go in the other direction. Develop for upstream first, and once it passes public review (clearly including Intel's own reviewers), and is applied, *then* split your own upstream commits as well, with the same subtree method. If people develop for the internal repos first (and pass internal reviews), then it is very tempting (and easy) to leave the public repo behind. (Obviously this only covers modules that are open source.) > (git subtree might > be able to help here as well, but there is no doubt that it would be > more steps.) Yes. Certainly not double the work, but more than developing for just one repo. Thanks Laszlo > 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. > > After splitting successfully, a single commit id is printed to > stdout. This corresponds to the HEAD of the newly created tree, > which you can manipulate however you want. > > Repeated splits of exactly the same history are guaranteed to be > identical (ie. to produce the same commit ids). Because of this, > if you add new commits and then re-split, the new commits will > be attached as commits on top of the history you generated last > time, so 'git merge' and friends will work as expected. > > Note that if you use '--squash' when you merge, you should > usually not just '--rejoin' when you split. > " > > Note the "Repeated splits" part... > > -Jordan > > ------------------------------------------------------------------------------ > _______________________________________________ > 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
