Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.So I have the following in a make file:
projects[collapsiblock][subdir] = "contrib" projects[collapsiblock][type] = "module" projects[collapsiblock][download][type] = "git" projects[collapsiblock][download][url] = "git://git.drupal.org/project/collapsiblock.git" projects[collapsiblock][download][revision] = "dea20849fb7535bbe5f7227fb4f614873620f117" projects[collapsiblock][patch][] = "http://drupal.org/files/issues/892340-11-Bringing-up-to-Drupal-7-no-prefix.patch"
Here's what I expect Drush make to do:
- Download the git repo specified.
- Try patching it with git, p1, fail
- Try patching it with git, p0, succeed
This is what happens with Drush 4 and Drush make 2, however with the new Drush 5 the third step there also fails. It fails because, for some reason, Drush decides that it's going to modify the info files after doing the git checkout, then because the patch touches the info files, it fails.
I'm not sure why Drush thinks it should start going around writing code when I've just asked it to download something?
So a possible solution would be to create a patch that applies to the Drush 5 make downloaded file, but then that patch wouldn't apply to the actual git repo, meaning that it's not useful to the module maintainer at all, and actually, not useful to the testbot either.
Is there a way to at least stop drush from writing code for me?
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | rewrite-after-pacthing-1528422-7.patch | 4.23 KB | fabsor |
Comments
Comment #1
moshe weitzman CreditAttribution: moshe weitzman commentedUse the --no-gitinfofile option.
We added that rewriting so that the cloned code works with Drupal's update status system.
Comment #2
jhedstromMarked #1536328: Drush make fails to build a particular patch as a duplicate.
I'm re-opening because it occurs to me that while
--no-gitinfofileis a valid workaround for local development, people cannot control that on d.o., and thus any distribution that needs to patch a .info file cannot be built.My initial thoughts on resolving it are to keep the logic of what the .info file should contain where it is now, but do the actual re-writing after patches have been applied.
Comment #3
jhedstromComment #4
Steven Jones CreditAttribution: Steven Jones commentedWould it be better to invert that option so you have to opt in to having the code downloaded re-written automagically?
Comment #5
jhedstromEven if we were to invert the option, we'd still need to fix the patching since d.o. will leave that on for packaging.
One concern I have with making that opt-in is that the majority of people won't do so, and then unless they are building sites with git deploy (and even then, always deploying with the --working-copy flag), all modules pulled from git are stuck in an unknown version for people who aren't aware of the .make file (eg, site admins using the update interface).
Comment #6
jhedstromMarked #1555964: Drush make modifies .info files making patches to info-files fail to apply as a duplicate.
Comment #7
Letharion CreditAttribution: Letharion commented#2 sounds like a good suggestion. It will preserve the idea of the added info, while still letting patches apply.
Comment #8
fabsor CreditAttribution: fabsor commentedHere is patch that moves the rewrite logic to MakeProject. While not ideal (it somewhat ties the makeproject class to the download method), it is the easiest way to go forward without doing a lot of rewriting.
Comment #9
fabsor CreditAttribution: fabsor commentedComment #10
jhedstromCommitted #8 (see 134990ea). I'm all for fixing this with a minimum of re-writing. Thanks fabsor!
Comment #11
jhedstromI committed a small follow-up fix that was missed in the initial review of this patch.
Comment #12.0
(not verified) CreditAttribution: commentedAdd code tags.