[development] Git best practices for client codebases

[larry at garfieldtech.com]

Yeah, I don't patch core often enough to need an elaborate patch 
management system. :-)  Just checking patch files that are clearly named 
into the repo is usually fine.

--Larry Garfield

On 3/1/11 10:30 AM, Marco Carbone wrote:
> "That keeps me on real releases, avoids unnecessary repository bloat,
> but still gives me a full history of all work on that project specifically."
>
> Well, svn or whatever VCS one is already using could be used this way as
> well. And it doesn't really address the issue about managing patches,
> which probably means that you either don't apply them (I doubt that), or
> you avoid overwriting them by careful management (a patches directory or
> careful monitoring of commit logs). But it's true that we aren't in the
> Wild West days of Drupal 4.7/5 anymore where core patches were more
> common than not, and so perhaps manual management is perfectly
> reasonable, and worth avoiding the ball and chain of storing every
> Drupal commit ever.
>
> -marco
>
> On Tue, Mar 1, 2011 at 11:13 AM, larry at garfieldtech.com
> <mailto:larry at garfieldtech.com> <larry at garfieldtech.com
> <mailto:larry at garfieldtech.com>> wrote:
>
>     I think the question is more about non-custom dev history; there's
>     little need for a client site to have the complete development
>     history of Drupal 4.3 in its repo, for instance.
>
>     Lately, what I've been doing/advocating is using Drush and real
>     releases to download stuff from Drupal.org (core, contrib modules,
>     etc.) and then checking the whole site into Git.  If I update a
>     module, I use Drush for that and then update the code in my Git
>     repo.  Then deploy to production using *my* git repo (which has my
>     full dev history but not every commit in every one of my projects
>     ever) and tags.
>
>     That keeps me on real releases, avoids unnecessary repository bloat,
>     but still gives me a full history of all work on that project
>     specifically.
>
>     --Larry Garfield
>
>
>     On 3/1/11 1:56 AM, Sam Boyer wrote:
>
>         I tend to advocate full clone. You're talking about a task that
>         version
>         control is designed for. Now that we've made the switch, IMO native
>         code:Git::bytecode:another VCS, or worse, patch stacks, etc. I don't
>         know what drush did before to "make this easy" - maybe pop off patch
>         stacks, update the module, then re-apply the patches? Fact is,
>         though,
>         nothing Drush could have done under CVS can compare to patching with
>         native Git commits: your patches can speak the same language as
>         upstream
>         changes, and you have all of Git's merge&  rebase behavior at your
>         fingertips to reconcile them.
>
>         There are some occasional exceptions to this, but I really do
>         think it's
>         a bit daft not to keep the full history. Keeping that history means
>         peace of mind that your patches (now commits) can be intelligently
>         merged with all changes ever made to that module for all time,
>         across
>         new versions, across Drupal major versions...blah blah blah.
>         Trading a
>         few hundred MB of disk space for that is MORE than worth it.
>
>         cheers
>         s
>
>         On 2/28/11 10:56 AM, Marco Carbone 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////
>
>
>
>