[development] Git best practices for client codebases
Kyle Mathews
mathews.kyle at gmail.com
Tue Mar 1 06:04:41 UTC 2011
Another option to consider is to track patches using Drush Make which
considerably lightens what you need to store in Git.
--
Kyle Mathews
Blog: kyle.mathews2000.com/blog
Twitter: http://twitter.com/kylemathews
Company: http://eduglu.com
On Mon, Feb 28, 2011 at 10:56 AM, Marco Carbone <marco.carbone at gmail.com>wrote:
> 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.
>
> 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.
>
> 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?
>
> -marco****
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20110228/44e42762/attachment-0001.html
More information about the development
mailing list