Monday, June 17, 2013

Drupal 8: Understanding the reroll process

ow that I'm trying to work on a slightly more involved reroll task, I'm coming up with a bunch more questions and some realizations about my workflow. First of all, I need to make sure to use my own time efficiently and not spend hours and hours trying to sort things out instead of taking a break and attacking a different problem. Secondly, I need to familiarize myself further with Drupal as a CMS before I have much chance of patching, rerolling and otherwise contributing to the open source project.

Also I badly need a better notetaking system because Blogger just lost my entire two page blog-post notes I had written here. @%#&! Text files, sadly, would be an improvement. I think I likely also said something about how to prioritize my time in order to become a highly useful Drupal contributor! This probably entails becoming more familiar with Drupal generally, working with it as a CMS, poking around the file tree etc.

This is the second reroll I've looked at, but the first to really be any fuss. Apart from sorting out the reroll system and infrastructure (which I think I've mostly got now), it's being able to parse the code on my own, rewrite it if necessary (?) and in this case update a year-old patch. This should actually be really easy, but I'm just figuring it out, so bear with me.

On applying the patch to the last commit it was known to work with, and then rebasing from the current version of 8.x, I got the following output. Only one conflict, which is nice. What do the lines marked "M" and "A" here mean?
$ git rebase 8.x
First, rewinding head to replay your work on top of it...
Applying: Applying patch from
Using index info to reconstruct a base tree...
M core/lib/Drupal/Core/StreamWrapper/LocalStream.php
A core/modules/system/tests/file.test
Falling back to patching base and 3-way merge...
CONFLICT (modify/delete): core/modules/system/tests/file.test deleted in HEAD and modified in Applying patch from Version Applying patch from of core/modules/system/tests/file.test left in tree.
Auto-merging core/lib/Drupal/Core/StreamWrapper/LocalStream.php
Failed to merge in the changes.
Patch failed at 0001 Applying patch from
The copy of the patch that failed is found in:
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
If something is deleted in HEAD but modified in the patch, wouldn't that mean it isn't needed any more and should also be removed from the patch? Or else that chunk of code has been moved elsewhere. I'd like to just glance at the current commit for 8.x, but Git Tower doesn't seem to want to let me do anything without committing any/all changes in my working branch. That seems rather unhelpful, so perhaps I'm missing something about branch checkout?

Why does it look like the reroll instructions are saying I need to rewrite the code in question? I don't have specific experience/context for this patch, so not confident enough to really understand what's going on with it.

Some steps to clarify for myself before I move on from this:

  • Understand output of rebase/apply above: M and A are pretty definitely "Modify" and "Apply," as I had assumed (other options were "Merge" and "Add.") "Modified" and "Added"! 
  • Is file.test still in HEAD? Looks like no? There is no file.test in HEAD, from what Git is telling me. Unfortunately, branching is still giving me issues, and now I seem to have a stray un-named branch and some commits that Git Tower is hung up on. meh. Trying again... Appropriate commit to pull, should I lose things here: git checkout -b symlinks-old fe01ab6e16a73a
  • Ah ha. Ok, so yes, file.test is no longer in core/modules/system/tests/, but it looks like tests have been sorted out a bit, so maybe that chunk of code is somewhere else. In theory, what should happen here is that I ... have 8.x to diff against, and a branch checked out for this reroll. I attempt to rebase in my working branch, and when it doesn't work, I ... add the bit of code that used to be in file.test to wherever it might be now, then git add (being careful not to add files.test back in to HEAD accidentally), then hit rebase --continue, then keep going with the reroll instructions.
  • If not, did the code in this patch move somewhere else? What I did here was an attempt at using grep to search for a line from the file.test file anywhere in the tests directory. No luck. Tested my grepping (sp?) skills by just searching "symlink" and that pulled up a lot, but not the specific line from the file this patch was attempting to modify. So, looks like that test was just deleted/moved somewhere in the last year.
  • Does that mean that the testing part of the patch is no longer relevant, or that it should be incorporated into a different testing file? This is something I'm not experienced with, so can't attack. Will add comment to this effect in a bit, once I double check that I'm not just missing something easy. The lovely mentors at office hours are great for nudging in the right direction.
  • What does comment #61 have to do with this? #61 is just updating the patch to match the changes to the D8 test files, which seem to move around a lot. I had a look at some of the previous patch versions, and my previous bullet is definitely the case. I just can't be quite sure of where to put the tests, or where they went if I'm just not finding them appropriately.

::Take break for dinner and something not-the-computer-screen. I would've succeeded with the two hour task routine if I hadn't lost my notes. Really. Hoping office hours tonight are helpful and that nothing breaks this time (last Monday I spent 75% of the office hours mopping up a broken bottle in the pantry. sigh).

Some goals for this week: brush up on PHP, play with a functional install of Drupal as a CMS so I know what I'm looking at working on the backend. Kind of excited about using Drupal.


  1. "...I'd like to just glance at the current commit for 8.x...": You can do so in Tower by going to the "Commits" tab and there navigate to the desired branch or even specific commit. You can even see the complete file tree at that state in time if you use the "Browse" tab to look at historic versions.

    Let us know via if you need more help and I'll do my best to explain.

    1. Yes, thank you! I was missing a few key points but think I've got a better grip on things now.