When a user is working from a local branch, display the release it was branched from

Definitely not a phase 2 requirement.

Subscribing. :D Also, moving to 7.x to move back to proper workflow. ;)

This is actually a pretty important feature IMHO. A very common reason for wanting to run VCS copy of a module is to manage patches on top of the official branch. This is incredibly easy now since you can just make a vendor branch and apply/merge/manage your patches there. Git deploy however will mark these vendor branches as needing security updates to official branches which isn't really an ideal situation for a site maintainer to be in.

Thank you for starting on this but I don't think we can call out to the git binary in git_deploy. We need to implement this functionality using the Glip library or by reading from the .git directory directly.

@g.idema It's not necessarily the issue that the git binary might not be in a user's PATH, but more that the version_alter hook is called every time which drupal fully loads. You shouldn't spawn a process on every drupal load. This happens anyways with traditional CGI setups, but mod_php and fastcgi avoid this spawning of a process on each page request because it is inefficient.

Also, you shouldn't chdir() in PHP just to run git on a directory. See git(1)'s --git-dir and/or --work-tree options.

In that patch in _git_deploy_get_version_from_hash(), you have an inconsistent use of == and ===. Also, you should use '' for constant strings in PHP instead of "".

Also, you should use proper Doxygen-style documentation for _git_deploy_check_drupal_version() and put a newline before the documentation comment block.

Sorry, I haven't tested any of the code and these are more minor formatting issues, but they bug me ;-).

can we do a switch in _git_deploy_get_version_from_hash() instead of the ifelse block and provide a default if only to fall out in some way?

count($core == 2) should probably be count($core) == 2

And as far as the "/' issue, just looking at the patch I don't see how its a functional change from the original since you're just adding code. Should maybe just go with the single quotes we all like here and just do the other fixes in some other issue. This isn't core where things are super pendatic and I'm still pretty sure even core patches would require you follow any new standards even if surrounding code doesn't.(not that single quotes for constant strings is a new convention)

Doxygen for the other new functions wouldn't hurt but they are well named so I'm not going to complain to much about that. I'm lazy too. :)

edit: clarify switch request.

Subscribing

> once you start merging, you go beyond the scope of the git_deploy module and can't expect it
> to resolve the original drupal project version you started with

I can understand there may not be an absolute way to determine which branch a commit is coming from.
Still, that does not mean git_deploy should not provide a solution for this issue.
Also limiting oneself to rebasing is a heavy restriction that prevents one great advantage of git: easy merging of branches.

I think the most reliable way to resolve this issue is to store the version of a module either in:
- the info file (a new property?)
- a new file.

I don't know drupal well enough to tell what pros/cons each solution has. I'd say a new file would avoid having to modify a tracked file.

The responsibility for ensuring the correct version is specified would be left to the user, and/or git_deploy would have to include some additional features for switching/setting to another branch/version of a module.

subscribe. this is needed so we don't get false security alerts from update status when we're ahead of a release in the dev branch.

i get "fatal: git diff header lacks filename information when removing 1 leading pathname components (line 5)" when attempting to apply the patch to 6.x-1.x listed at #15.

OK, thanks. I applied the patch from #15. I still get security warnings on the available updates page, unfortunately. (For reference, I'm using the nodequeue module, with the most recent 6.x-2.x branch, which is ahead of the security release at 6.x-2.9.)

and that's obviously the 6.x-3 patch for git deploy :P

Finding a more accurate version number with source preference, evaluating the labels first, than the branches, than HEAD.

Subscribing- not sure if I'm doing this right, but #23 doesn't seem to be working for me. I cloned a project repo from d.o, checked out the most recent tag, created a new branch based on that tag, and committed a couple of small changes. The update status for the project says 'not supported' and just lists my branch name for the version.

Here's a patch (against clean 7d290a8 from master) which walks up the tree (like #15) and prefers tags over branches over heads (like #23).

I've removed the final bit which equates "master" with the latest release, since that's extremely dangerous; when you just put a checkout of master on a server and lets it sit there without updating, you won't ever be notified of security updates.

This patch also drops ver_scope stuff from #23, since I honestly didn't understand it and it didn't seem necessary. I've relaxed the regex a bit as well, since it didn't allow for suffixes like -dev, -alpha1, -beta2 and -rc3.

I got rid of the various if()-checks in favor of a simple regex. The if checks just gave me several PHP warnings of unset indexes.

Instead of applying the patch you could also pull and merge from http://dev.solide-ict.nl/git-pub/git_deploy.git (the patch corresponds to the commit with hash 3546256)

Would not apply against 6.x branch

Could you possibly make the patch against 7.x-1.x? We're committing patches to the 7.x-1.x branch before they go into 6.x-1.x.

My patch was against 7d290a87d9d5f0b5dc59e (current HEAD) in the 7.x-1.x branch (as you can see in the git history)

The current HEAD of 7.x-1.x is b1e1fc5, and the patch from #25 fails to apply against it. :/

% git rev-parse HEAD
b1e1fc53d776124e96413323e30f582b3cc4c2de
% git apply git_deploy-issue1011170.patch
error: patch failed: git_deploy.module:104
error: git_deploy.module: patch does not apply
% patch < git_deploy-issue1011170.patch
patching file git_deploy.module
Hunk #1 FAILED at 104.
1 out of 1 hunk FAILED -- saving rejects to file git_deploy.module.rej

You're right, I messed up with Git again. Here's a new patch

Here's a patch for D6 for all who are interested.

The only issue that I'm noticing is that if I checkout a specific version of module foo and that version == the dev version then the version is reported as "dev" rather than the specific version number. This is only really an issue for security releases - the Update module incorrectly reports them as needing an update. Though I'm not sure if that's a bug in this patch or not.

Think I'm gonna need to step in and take this over, perhaps. Assigning to myself to help me remember.

Thank you Sam. I have no time but Freso has been available. Ping him on IRC if you'd like to work with him.

In the 2.x branch git_deploy will now display the most recent tag with {number of commits since tag}-dev.

For example if there has been one commit to the local repo since 7.x-2.0 was tagged the version will be displayed as: 7.x-2.0.1-dev. This allows dependency checking to work correctly.

This functionality will not be added to the 1.x version of git_deploy which uses Glip.