On 06/03/2015 03:35 PM, Kirkendall, Garrett wrote:
> The fact that git only works on a complete repository makes it impossible to
> pull a complete EDKII tree, as some sort of external, such that the package
> folders go into the root directory as expected by the EDKII build
> infrastructure. This is why I assume the splitting up of packages into
> separate repos was suggested. In Linux, it would be easy to pull the EDKII
> tree into a subdirectory and make links from folders of EDKII into the root
> directory. Git even seems to be happy following these links and showing
> status of the complete subproject, etc.
Yes, that's definitely an issue.
> Then there's Google repo. Which, under Linux at least, seems to fit the bill
> relatively nicely. It allows you to specify a sub repository branch at its
> HEAD, or at a revision. It gives you some nice functionality to see what has
> changed in subprojects, but you have to use the git tools to commit to each
> individual subproject. The downside for Windows, Google repo heavily depends
> on the OS file management capabilities of Linux and therefore is a
> non-portable python tool that must be run in a Linux like command-line
> environment. Cygwin provides a relatively Linux capable command prompt
> environment in Windows and can run google repo, but with some less than
> desirable side effects. If you've played with google repo, it does a lot of
> things with symbolic links. Cygwin can be configured to create windows
> symbolic links when the target file/directory exists. Google repo creates
> symbolic links even when the target doesn't exist so, you can't force strict
> native symbolic links. Since the .git subdirectory in subprojects is full of
> symbolic links back to the .repo directory, you are then forced to do every
> bit of the git interaction within a Cygwin prompt. That's OK with me because
> I know enough about Windows command-line and Linux command-line to be pretty
> dangerous to myself. Our other developers are not as Linux knowledgeable, so
> now they will have to learn about Linux command-line and git command-line to
> do the same thing they had a nice pretty GUI in Windows and subversion. (I
> know about esrlabs/git-repo, but it doesn't look like it gets much love.)
You could also take a look at gitslave ("gits",
http://gitslave.sourceforge.net/). It works a bit like submodules, in
that you can add a repository as a subdirectory, and manage it without
too much trouble. Essentially it automates running git commands across
a super-repo and sub-repos, with some sugar for aggregating the results
into a readable whole. But at the end of the day, you're still trying
to coordinate multiple git repositories.
Gitslave is just a perl script. I've never tried using it on Windows,
but I'd imagine it would work.
> ...
> One last thought, I assume there would be some strategy where we could start
> with the EDKII tree as our base project and then put our platform code in.
> Then use merging to pick up EDKII modifications, but as Jordan said, that has
> its own concerns.
>
> Thanks to anyone that took the time to read this whole thing. Any thoughts
> would be greatly appreciated.
If you want to track upstream TianoCore, but don't want to have packages
you're not interested in cluttering up your workareas, you could just do
your development in a branch in which you've "git rm"ed the unneeded
code. Merges should recognize that you've deleted the files. The
unwanted code will still be in the .git data, but disk is cheap....
It's possible to do all sorts of things with git filter-branch. For
instance, you could completely remove unnecessary packages and their
history from the upstream TianoCore code for your in-house tree. Or you
could grab a package, along with its history, out of one project to use
in another project. Of course, the git commit IDs change when you do
that, so you can't just git-pull from an original to fetch updates...
you'd need to write some additional scripts to grab and filter new
upstream commits, or just wrangle patches manually. But you have the
full power of git to use within the project tree, with no extra tools or
wrappers for daily development.
That's essentially the flow I've used. At the beginning of a project we
use a filter-branch script to copy relevant parts of the previous
project (sometimes with significant pathname rewriting) into the new
project. Then we manually apply patches between them (using git's patch
generation and application facilities, of course, or a helper like
stgit) as necessary. We don't have many such patches to merge... if we
did, we'd probably have to find a different solution.
So things don't need to be pretty... they just have to work well in the
common, daily cases, and not be utterly broken in the uncommon ones
(like starting new projects.)
--
Brian J. Johnson
--------------------------------------------------------------------
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
