Posted by jhedstrom on July 19, 2012 at 7:54pm
3 followers
| Project: | Drush |
| Component: | Make |
| Category: | bug report |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Drush make currently just rewrites the version in the .info file to be the git hash in the event of a git clone from a hash. Drupal.org rewrites using more ineligible logic (eg, 5 commits past last stable, etc) so as to not cause panic when somebody views the available updates screen from within Drupal. The code d.o. uses is here: http://drupalcode.org/project/drupalorg.git/blob/refs/heads/6.x-3.x:/dru...
Comments
#1
Turns out this was actually a regression. Tagging the .git directory for removal after the build instead of removing it at the time of download allows the logic found in
drush_pm_git_drupalorg_compute_rebuild_version()to work properly again.Setting to needs review for now, but will commit shortly.
#2
The regression happened in this commit 134990ead6f69a6b152b1a8f12b22cbad76bc6e6. Also bumping priority since builds done without this get the .info file version set as the revision, which causes scary warnings from the update module about unsupported releases.
#3
Updated patch with tests.
#4
Committed in 6dfb696.
#5
This needs to be committed to 5.x as well.
#6
Committed in 1d3d650.
#7
Automatically closed -- issue fixed for 2 weeks with no activity.