Now that Git is live on drupal.org, we should fix the integration with it.
- We should properly checkout a branch or a tag, depending on the cases. The method suggested in the Git instructions (git clone --branch) cannot actually be used because (1) it is only supported starting Git 1.7, (2) we don't know from the release feed if the "tag" is a real tag or is actually a branch;
- We should get the tag name directly from the feed instead of guessing (this was not possible before the migration);
- The "stable" repositories (one commit per release) have not yet been officially deployed on drupal.org, so we need to remove support for them
Comments
Comment #1
damien tournoud commentedFull Git workflow :)
Comment #2
moshe weitzman commentedComment #3
kotnik commentedThese two files need to be executable. Right?
Powered by Dreditor.
Comment #4
greg.1.anderson commentedIt is questionable whether drush.php needs to be executable. It does not need to be if you use the drush script, or if you use
php drush.php status. It does need to be executable if you ever call it directly viadrush.php status. I don't know that we need to support that any more, but I suppose it does not hurt.Comment #5
jonhattanI'm testing the patch. I think we need also a fix for update actions.
ps. execute permissions should be a separate issue. I'll not commit those changes here. Note also examples/helloworld.script is executable.
Comment #6
msonnabaum commentedIts probably a good idea to have "filemode = false" in ~/.gitconfig so we don't get patches that change file modes.
Comment #7
kotnik commentedYes, but drush script needs to be executable.
Comment #8
damien tournoud commentedCan we stop discussing the mode changes? They are obviously not part of this patch, and I am not exactly sure what happened.
Comment #9
damien tournoud commentedNew patch without the diff change. I know what happaned: I accidentally run
drush dl drush, and apparently_drush_recursive_copy()does not keep the file modes. See #1073768: drush_copy_dir() does not keep file modes.Comment #10
owen barton commentedTested this out and it works great. Considering Drush git_drupalorg handler is currently completely broken even for the dl command I went ahead and committed the latest patch to HEAD - feel free to post further review/refinements here (I didn't test with upc yet). I think we should also backport this to Drush 4.x.
Comment #11
msonnabaum commentedI've also been testing this and it works so far for me. Committed to 4.x.
Comment #12
greg.1.anderson commentedCool. I haven't tested it myself yet, but setting to 'fixed' per #10 and #11. Thanks.
Comment #13
likewhoa commentedThanks for this patch it works well on my test, but I did found it unneccessary to use 'executable --version' for checking if it's available, the proper way is to use the hash utility.
As you can see the advantage is crystal clear, that .002s can be used to think of that cool new function for your module :)
Comment #14
greg.1.anderson commentedHash may be faster, but I'm going to suggest that we not switch to this technique for detecting git (although it may be useful elsewhere in drush).
As I recently noticed on some of my older systems, git 1.6.x says only "Unable to clone project xyzzy from git.drupal.org." Maybe we should spend even a couple more us and actually parse the version, and make sure that it is 1.7 or later.
Comment #15
likewhoa commentedHere you go, see what can be improved on it. This patch includes what I added before plus the version checking for >=1.7 on git executable, I still think we should leave 'hash' to detect executable but 'git --version' works too but not needed since we just want to check if executable is available not check version, we do that after :D
Comment #16
jonhattanwhat about windows compatibility?
Comment #17
greg.1.anderson commentedAgree; awk '{print$3}' should be done in php.
Comment #18
likewhoa commentedWhat is this windows you speak off? :D
Comment #19
likewhoa commentedSorry for the noise, had to fix my grammar :D
Comment #20
greg.1.anderson commentedCode looks good.
Comment #21
jonhattan*
hashis a sh/bash/dash/? subcommand. I see it is not available in csh/tcsh/?. Surely neither in windows.* there's still a unchanged
curl --versionin the code.* in the case of git we don't profit the gain in milliseconds as it also needs a call to
--version. I don't see the interest for such a gain when the command is not found.Comment #22
greg.1.anderson commentedMaybe we should take just the git version check, and skip hash. It would be possible to make a wrapper
drush_executable_exists, but it seems that if we took the trouble to do that, it should also provide a service to require a minimum version.Perhaps the minimum version could be passed in as an argument with a default value of FALSE or NULL; if not Windows and no minimum version supplied, then use hash, otherwise use
fn --version.Comment #23
owen barton commentedI say stick with --version all round for now, 2ms is really not too bad. I am working on a sqlite wrapper for convenient local RW storage for Drush, which could be used to cache these results, which should give us both simple non redundant cross-platform code, and high performance.
Comment #24
likewhoa commented@jonhattan the unchanged --version for curl needs to stay there because some older versions of curl return 1 while newer ones don't, hence the dual call to 'curl --version'.
Attached is an updated patch that switches back to 'app --version'. The reason for the dual 'git --version' is that drush_shell_exec returns only the first number for 'git --version' instead of '1.7.4.1' in my case when exploding into an array. Perhaps this needs to be looked at later.
Comment #25
greg.1.anderson commenteddrush_shell_exec returns TRUE to indicate success. Call drush_shell_exec_output() to get the data that was written to STDOUT.
Comment #26
likewhoa commentedhere you go.
Comment #27
greg.1.anderson commentedCommitted to master. Thanks.
Comment #28
msonnabaum commentedI'm confused. Do we know what will/won't work with git clients older than 1.7 with drush?
I'd hate to introduce this dependency in drush 4 unless we have pretty specific reasons. If its just the --branch option, we could always clone it like normal and then just checkout that branch afterwards.
Comment #29
greg.1.anderson commentedI confirmed that
drush dl anymodulefails on 1.6.x with an inscrutable error message without this patch. I did not try to fix it, though; if anyone wants to try to maintain old versions of git, we could re-open...Comment #30
msonnabaum commentedSince no one else has asked for this in drush 4, and 5 is already out, I'm considering it not worth backporting.