On 4 June 2015 at 04:41, Andrew Fish <af...@apple.com> wrote: > > On Jun 3, 2015, at 7:03 PM, Jordan Justen <jordan.l.jus...@intel.com> wrote: > > > You can commit to svn from git. > git svn rebase > git svn dcommit > git svn info > > > git svn makes svn based development sane, but it is inferior. > > It doesn't really support all git features. > > It also has a natsy gotcha where equivalent branch get artificially > split. > > For example, my 'git-svn' at top-of-tree is never considered the same > as origin/master. > > This prevents things like 'git merge' from being usable. Of course, > 'git merge' can't be used with git svn anyhow... > > It also causes the source control history to be needlessly duplicated > for the two branches. > > An example of how this wastes time is that I do my development based > on the git origin/master branch. But, when it comes time to commit to > svn, I checkout the git-svn branch, run git svn rebase, cherry-pick > all the changes to the git-svn branch, and finally use git svn > dcommit. Contrast this to just running 'git push'. >
Actually, running 'git rebase origin/master --onto remotes/git-svn' from your topic branch works just fine (after a git svn fetch) so there is no need to cherry-pick a patch at a time. There is not even really a need to have a local branch that tracks the svn remote. As I said in my earlier reply, I prefer Git over SVN any day of the week, but I don't have /that/ many issues with the current situation. So am I correct in understanding that the split view into separate submodules is primarily for the benefit of the downstream, and most development of EDK2 will occur in the EDK2 project? In that case, it is really just a matter of providing a read-only split view, and using git subtree does sound like a promising approach. But otherwise, retaining the SVN repo but making it the slave rather than the master, with some automation in place to keep it in sync sounds reasonable as well, since it will allow the continued use of svn:externals as before. Or perhaps we should just do both? In any case, I think the consensus is that the EDK2 upstream should remain a single project if it moves to Git. If anyone disagrees with this observation but hasn't chimed in yet, please speak up and motivate your position. -- Ard. ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
