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
