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. The main
disadvantage to them would be to get things upstream, they'd have to
convert their commits to the merged unified tree. (git subtree might
be able to help here as well, but there is no doubt that it would be
more steps.)
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
