On Thu, Jun 4, 2015 at 9:34 AM, Roy Franz <roy.fr...@linaro.org> wrote: > 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 > (replying to myself)
I did some quick experiments with git subtree split, and it the result of repeated "subtree split" commands are suitable for pushing to a single branch on a remote repository. This can be used to create read-only "module" repositories that only contain a single directory. Each "subtree split" command starts from the beginning of the repository history - it is not incremental, but the results of later iterations consist of new commits being appended to the existing, stable, history. One downside is that the subtrees have different commit ids than the master repo (but they are stable within the subtree, even when regenerated.) I think this is a viable strategy. There is also no reason that the splitting of of the main repository into subtrees needs to be done publicly. The subtrees of interest can be made by the organizations that are interested in them. Everybody will get the same results from "git subtree split --prefix=ArmPkg -b subtree-ArmPkg". I think this makes more sense vs. the submodules, since here we are really trying to break up a single project into tiny pieces, rather than pull together a collection of separate projects. Comments??? Thanks, 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
