Another option to consider is to track patches using Drush Make which considerably lightens what you need to store in Git.<div><br></div><div>--<br>Kyle Mathews<br><br>Blog: <a href="http://kyle.mathews2000.com/blog">kyle.mathews2000.com/blog</a><br>
Twitter: <a href="http://twitter.com/kylemathews">http://twitter.com/kylemathews</a><br>Company: <a href="http://eduglu.com">http://eduglu.com</a><br>
<br><br><div class="gmail_quote">On Mon, Feb 28, 2011 at 10:56 AM, Marco Carbone <span dir="ltr"><<a href="mailto:marco.carbone@gmail.com">marco.carbone@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Since a Git clone downloads the entire Drupal repository, the Drupal codebase is no longer so lightweight (~50MB) if you are using Git, especially as if you clone contrib module repositories as well.<br><br>With CVS, our usual practice with clients was to checkout core and contrib using CVS, so that we can easily monitor any patches that have been applied, so that they wouldn't be lost when updating to newer releases. (Drush makes this particularly easy.) This is doable with Git as well, but now there seems to be the added cost of having to download the full repository. This is great when doing core/contrib development, but not really necessary for client work. This is unavoidable as far as I can tell, but I don't think I'm satisfied with the "just use a tarball and don't hack core/contrib" solution, especially when patches come into play.<br>
<br>Is there something I'm missing/not understanding here, or does one just have to accept the price of a bigger codebase when using Git to manage core/contrib code? Or is managing core/contrib code this way passe now that updates can be done through the UI?<br>
<font color="#888888">
<br>-marco<em></em><em></em><span></span>
</font></blockquote></div><br></div>