[commits] [Wiki] changed: Project/SplitGitRepo

[Michael Slusarz]

slusarz  Wed, 19 Jun 2013 23:08:47 -0600

Modified page: http://wiki.horde.org/Project/SplitGitRepo
New Revision:  2
Change log:  Add verified commands to split repo

@@ -18,9 +18,9 @@

  Going to try to sum up what I think is forming as a consensus.

  # Moving applications and framework packages to separate repos seems  
to be the most supported idea.
- * GitHub allows unlimited public repos, so we are good there
+ * !GitHub allows unlimited public repos, so we are good there
   * Can maintain all history.  See  
https://help.github.com/articles/splitting-a-subpath-out-into-a-new-repo
   * Might be a bit more unwieldy to work with (current monolithic  
repo allows commits across applications; but it might be a good thing  
to require different commits for each application for a more granular  
approach at adding features/fixing bugs.)
  # Talk of using git subtree(?)
   * http://log.pardus.de/2012/08/modular-git-with-git-subtree.html
@@ -31,16 +31,45 @@
   * Additionally, whatever way we switch to will also need to be  
scripted so we would be in no different place than we are currently.
   * No solution is going to work out-of-the-box.
   * Use PHP Composer to help automate the process of generating a  
usable build from git (http://getcomposer.org/).

-...
+----

  And the last time I chatted with Nils about composer it didn't have  
support for the installation of web assets - so for Horde the result  
would be a mixture of using composer and PEAR package definitions. I  
have no clue how much work it would be to get composer on par with  
PEAR in that area. Nils suggested that this should not be too hard.  
But the components helper we have should also be capable of managing  
PEAR and composer package definitions in parallel.
  I would assume we would do something like maintain package.xml files  
and then use the components script to create a composer.json file.  We  
could probably leverage this code:

  https://github.com/claylo/conductor

  BTW, adding yet another advantage to separate repositories: this  
greatly simplifies/improves continuous integration reporting.  Not  
only does this drastically take the time to check a commit, it more  
directly targets the actual changes the commit made.
+
+----
+
+As far as splitting the repo, I can verify the following process  
works.  It is necessary to do ALL the steps - {{git filter-branch}} is  
not enough as it leaves the Git repo still containing all the old  
references (i.e. the Git repo is still 150 MB).
+
+<code>
+# This command is best done on the same machine as a copy of the  
Horde repo, to cut down on network usage
+git clone [repo] [newrepo]
+
+cd [newrepo]
+git remote rm origin
+
+# Replace "XXX" with the prefix of the tags YOU WANT TO KEEP (all  
other tags will be removed)
+git tag -l | awk '\!/^(XXX-.*)$/ {print $1}' | xargs git tag -d
+
+# Replace XXX with the pathname of the Horde application/framework library
+git filter-branch --prune-empty --subdirectory-filter XXX  
--tag-name-filter cat -- --all
+
+git update-ref -d refs/original/refs/heads/master
+git reflog expire --expire=now --all
+git gc --aggressive --prune=now
+
+# At this point, the git pack is still humongous (150MB). These steps  
are necessary to trim the fat:
+cd ..
+# file:// is necessary!  Hardlinking won't work!
+git clone file://[newrepo] [newrepo2]
+
+# newrepo2 now contains the trimmed version of the git repo (a couple  
of MB vs. ~150 MB)
+</code>

  ++ Resources

  ...