Refreshing a Stale Patch with Git

Topics: 

Git is so smart about merging that it's often possible to referesh a stale patch in the queue using just git, without even looking at the contents of the patch. (I'm not saying you shouldn't look at any patch you post, just that git will often do all the refeesh work for you.)

  1. Update to the latest version of the project you're working with.
  2. Use git log to find the hash of a commit near or just before the time the patch was posted.
  3. Create a branch from that commit: git checkout -b <date_based_branch_name> <commit_hash>. (I often use the date for the branch name: git checkout -b aug10 <hash>
  4. Apply the patch. It should apply cleanly unless there was already something wrong with it when it was created.
  5. Use git add and git statusto make sure that all your changes are staged, then commit the results.
  6. Create a new branch for the updated patch. I'll use git checkout -b bundles_removed_1245332_04 origin/8.x, which branches off of 8.x just for this feature branch.
  7. Merge the date-based branch: git merge <date_branch>
  8. If all goes well, you have a clean merge, and you can create a patch. In this case, git diff origin/8.x >drupal.bundle_warning_1245332_04.patch
  9. If you still have a merge conflict, you probably only have the really relevant part of the conflict (changes actually made in your patch which conflict with changes which have been committed since the issue was last active.) In that case, you can use git mergetool to reconcile the differences, but that's for another session.

For just updating a patch that was obsoleted by the D8 core files move patch in November, see xjm's excellent, focused article.

Here's the screencast:

Using Scrapbook Plus to capture the Drupal issue queue for a plane ride

Topics: 

Webchick tweeted about favorite ways to capture the issue queue for long plane rides. I use the Scrapbook Plus Firefox addon.

Here's the quick screencast, followed by the recipe.

Using Scrapbook Plus to Capture the Drupal Issue Queue for Plane Rides from Randy Fay on Vimeo.

Drupal Deployment with Git Submodules

Topics: 

[Update October 2013: Warning: While I found submodules extraordinarily easy to use, especially when contributing back changes, I failed at nearly every turn to successfully involve other people with them. They always had unnecessary technical problems. So I have reverted back to a single repo for the entire project.]

(There are screencasts illustrating these concepts at the bottom.)

I've been using git submodules for Drupal site deployment for quite awhile now, and I wanted to share my experience (for good and bad) with others who might be interested in using submodules (and to solicit comments from those who know how to do it better).

What are git submodules?

First "git submodules" have nothing to do with Drupal modules. They're a way of including one git repository inside another, in its entirety, and managing it from within the parent repository.

In a regular git repository, you have one .git directory in the root directory of the project that contains the entire history and all the revisions for that project. Every change in the project is tracked in that one .git repository.

Drush, File Permissions, and Web Servers - Lots of things can go wrong

Topics: 

The marvelous drush makes an enormous number of things possible that would otherwise be tedious at best, and allows us to automate a shocking number of Drupal tasks.

But it has a dark side. Drush does tasks that would normally be done by the web server (cron, update.php, enabling modules), and that means that it can leave files laying around that the web server may not be able to access and control. It also does jobs that would normally be done by a site maintainer (drushpm-download, drushpm-updatecode) from the command line. These should create files that are not writeable by the web server.

Drupal Community Conflict Resolution (and Twitter)

Topics: 

We value our community like a family, and have put loads of energy into the Drupal world. But we have some problems, and it's probably time for some discussion about our community manners and approach to problem-solving. We have the excellent Drupal Code of Conduct (copied from Ubuntu's model) but it doesn't yet address a number of specifics (especially conflict resolution). So I'd like to throw some ideas into the wild.

First of all, Controversy is not a bad thing. It's not a problem when people disagree on issues, even if they permanently disagree. It is a bad thing, though, when people start campaigns (on Twitter or otherwise) without understanding the problem or trying to resolve it directly. Feelings can be hurt, the community can be divided, contributor energy can be sapped, and it's mostly not the most likely way to resolve the situation anyway. Why do that?

What can the Drupal Community do about Burnout?

Topics: 

This post is the last in a series in preparation for the Burnout core conversation at Drupalcon London. The first post discussed what burnout is; the second is about what individuals can do about burnout; the third was about how the Drupal Community burns people out.

The key point of this series is that we need to do strategic thinking as a community about how to treasure and keep our wonderful contributors. That's the point of the core conversation. It will not be a support group for people to share their burnout stories, but a gathering to think strategically about how the community can prevent or heal burnout to protect and keep our members.

How Does the Drupal Community Burn People Out?

Topics: 

This post is one of a series in preparation for the Burnout core conversation at Drupalcon London. The first post discussed what burnout is; the second is about what individuals can do about burnout, and the final one will discuss what the Drupal community can do to prevent and deal with burnout. Also, please see Arianek's excellent post about burnout.

One of the striking things about the Drupal community is that so many of us have such loose or nonexistent boundaries between work and home, Drupal and work, hobbies and work. And, being techies, we're always connected. The result is that Drupal can dominate every aspect of our lives. Not so good.

What Can Individuals Do To Prevent Burnout?

Topics: 

This post is one of a series in preparation for the Burnout core conversation at Drupalcon London. The first post discussed what burnout is; this one talks about what individuals can do about burnout, and the final two will discuss what about burnout is distinctive to the Drupal community, and what the Drupal community can do to deal with burnout. Also, please see Arianek's excellent post about burnout

There are dozens, even hundreds of books addressing individuals and burnout. I was amazed how many of them are aimed squarely at church members, pastors, and other caring professionals. Interestingly enough, the Drupal community can be a bit like many churches: plenty of needy people, lots of ideas, an amazing amount of work that "ought" to be done, and most of it done by volunteers or vastly overloaded professionals. These books have pretty uniform advice to the individual for dealing with burnout, and of course it's what you already know:

What is Burnout?

Topics: 

This article is one of a series in preparation for the Burnout core conversation at Drupalcon London. This article will discuss what burnout is; future posts will cover how individuals can respond to burnout, what about burnout is unique to the Drupal community, and what the Drupal community can do to deal with burnout.

What is burnout? Many of us "just know" the answer to this, as we've we've struggled with it ourselves in our professional, personal, or community work. I found a couple of high quality discussions of burnout. The first is the book The Truth about Burnout: How Organizations Cause Personal Stress and What to Do About It1, written by the leading researcher in the field, Christina Maslach. The second was the seminal article Burned Out2 from Scientific American Mind magazine.

Pages

Subscribe to RandyFay.com RSS