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

damien tournoud’s picture

Status: Active » Needs review
StatusFileSize
new4.74 KB

Full Git workflow :)

moshe weitzman’s picture

Assigned: Unassigned » jonhattan
kotnik’s picture

 mode change 100755 => 100644 drush
 mode change 100755 => 100644 drush.php

These two files need to be executable. Right?

Powered by Dreditor.

greg.1.anderson’s picture

It 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 via drush.php status. I don't know that we need to support that any more, but I suppose it does not hurt.

jonhattan’s picture

I'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.

msonnabaum’s picture

Its probably a good idea to have "filemode = false" in ~/.gitconfig so we don't get patches that change file modes.

kotnik’s picture

Yes, but drush script needs to be executable.

damien tournoud’s picture

Can we stop discussing the mode changes? They are obviously not part of this patch, and I am not exactly sure what happened.

damien tournoud’s picture

StatusFileSize
new4.23 KB

New 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.

owen barton’s picture

Tested 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.

msonnabaum’s picture

I've also been testing this and it works so far for me. Committed to 4.x.

greg.1.anderson’s picture

Status: Needs review » Fixed

Cool. I haven't tested it myself yet, but setting to 'fixed' per #10 and #11. Thanks.

likewhoa’s picture

StatusFileSize
new1.97 KB

Thanks 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.

drush # time git --version
git version 1.7.4.1

real    0m0.002s
user    0m0.001s
sys     0m0.001s
drush # time hash git     

real    0m0.000s
user    0m0.000s
sys     0m0.000s

As you can see the advantage is crystal clear, that .002s can be used to think of that cool new function for your module :)

greg.1.anderson’s picture

Title: Fix Drupal.org Git integration » Improve git executable check
Category: bug » feature
Status: Fixed » Active

Hash 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.

likewhoa’s picture

Here 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

jonhattan’s picture

Status: Active » Needs work

what about windows compatibility?

greg.1.anderson’s picture

Agree; awk '{print$3}' should be done in php.

likewhoa’s picture

Status: Needs work » Needs review
StatusFileSize
new2.55 KB

What is this windows you speak off? :D

likewhoa’s picture

Sorry for the noise, had to fix my grammar :D

greg.1.anderson’s picture

Code looks good.

jonhattan’s picture

Status: Needs review » Needs work

* hash is a sh/bash/dash/? subcommand. I see it is not available in csh/tcsh/?. Surely neither in windows.
* there's still a unchanged curl --version in 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.

greg.1.anderson’s picture

Maybe 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.

owen barton’s picture

I 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.

likewhoa’s picture

Status: Needs work » Needs review
StatusFileSize
new1.28 KB

@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.

greg.1.anderson’s picture

Status: Needs review » Needs work

drush_shell_exec returns TRUE to indicate success. Call drush_shell_exec_output() to get the data that was written to STDOUT.

likewhoa’s picture

Status: Needs work » Needs review
StatusFileSize
new1.2 KB

here you go.

greg.1.anderson’s picture

Assigned: jonhattan » msonnabaum
Status: Needs review » Patch (to be ported)

Committed to master. Thanks.

msonnabaum’s picture

I'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.

greg.1.anderson’s picture

I confirmed that drush dl anymodule fails 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...

msonnabaum’s picture

Status: Patch (to be ported) » Fixed

Since no one else has asked for this in drush 4, and 5 is already out, I'm considering it not worth backporting.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.