Currently git_deploy works well with lightweight tags but doesn't do anything with signed or unsigned tags. Support should be added.
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | resolve_annotated_tags-d6-1007890-13.patch | 2.66 KB | pfrenssen |
| #11 | resolve_annotated_tags-1007890-11.patch | 2.69 KB | pfrenssen |
Comments
Comment #1
halstead commentedI explored a .git directory and didn't find an easy way to get the commit hash referenced by a tag object. The glip library if seen used elsewhere doesn't seem to have any support for tag objects either. The version of glip at https://github.com/Upliner/glip does have a GitTag class but I haven't tested it.
Comment #2
chris.stone commentedI've been working with the glip lib to see if we can find a way to have git_deploy pull the correct time for commits. Perhaps to solve both issues and possibly any more that may appear the module should be re-coded using glip to access the repo information?
Comment #3
sdboyer commentedThis does seem pretty important as I do expect we'll start to see a lot of annotated tags.
Comment #4
eliza411 commentedAssigning this for Sprint 10. If you won't be doing it, please look for someone who will and unassign yourself.
Comment #5
halstead commentedPosted in wrong issue. --
I'll start looking at this now.
Comment #6
halstead commentedI've tested this and it works. Not my most elegant patch but it works. I'd love a review.
Comment #7
halstead commentedHere is how I'm testing this:
You will need to tag a release with an annotated tag. So "git checkout 6.x-1.x" then "git tag -a 6.x-1.2". The available updates page before the patch will still show 6.x-1.x even after tagging the release. After the patch you will see 6.x-1.2 on the available updates page.
Tags are supposed to take priority over branches so if a branch tip and a tag both point to the same commit we should use the tag. With the patch this is the behavior I see.
Additional test ideas are welcome.
Comment #8
halstead commentedHere is some minor clean up based on feedback from Freso in IRC.
Comment #9
pfrenssenThis works perfect. Reviewed and tested with a real case: the ImageField project which is using annotated tags.
For completeness the _git_deploy_find_tag_for_commit() function could use a description.
Comment #10
dwwWorks fine in my testing, although it revealed a bug in glip when it's trying to parse repos that have
jacobsingh <> ...-- there's an assertion failure since the preg_match() assumes a non-empty email address. I fixed it by adding a single ? to the regexp to handle the case where the email is empty. See attached patch (seems like overkill to handle this 1 byte fix via a github fork). ;)Anyway, I'm setting this to "needs work" for a few reasons:
A) It's not obvious to me why _git_deploy_find_tag_for_commit() is a separate function. It's only called once. Furthermore, it duplicates all the work of instantiating a Git object, calling revParse(), etc. That seems like a big inefficiency to me for no clear gain.
B) If it's going to remain a separate function, ideally it should be documented. And if it's a separate function since someone else might want to use it some day, it shouldn't use the _ namespace -- it should just be a public function.
Comment #11
pfrenssenI updated the patch from #8 with the suggestions from #10. I chose to remove the code from the private function to avoid making a new instance of the Git object.
Comment #12
pfrenssenstatus
Comment #13
pfrenssenThe patch in #11 is against the master D7 branch, here is the same patch for the D6 version.
Comment #14
pfrenssenThis is a bug, not a task.
Comment #15
fenstrat#11 works well. Haven't tested the D6 version in #13.
dww's glip regex patch in #10 still needs looking into.
Marked #1181258: git_deploy does not report a version for some modules as a duplicate of this.
Comment #16
pfrenssenIt seems like some more work needs to be done. I was about to update a website and got different results with the patch in this issue, and the one in #1181258: git_deploy does not report a version for some modules
Drush up without git_deploy:
With unpatched git_deploy 7.x-1.x:
With the patch in this issue:
With the patch in #1181258: git_deploy does not report a version for some modules:
These results differ greatly. Many modules and Drupal core itself are not recognized depending on which patch is used.
Comment #17
Anonymous (not verified) commentedThe d6 patch in #13 works fine for me.
I had a problem with the annotated tag for admin_menu 6.x-1.8, but now all is fine for that module.
Comment #18
Freso commentedRe: #17:
The problem with admin_menu lies (or lay, it seems) with admin_menu and not git_deploy: #1251232: Unable to show correct version at admin/reports/updates if managed by Git
Comment #19
darrell_ulm commentedQuestion has the patch in http://drupal.org/node/1007890#comment-4560538 been applied to the D6 dev branch? Some of the patches to get the D6 (or D7) version working seem to apply easily, and it would be awesome to have them in the releases.
Thank you.
Comment #20
chris.stone commentedThe patch from http://drupal.org/node/1007890#comment-4560538 has not been committed as of yet. Considering that the 2.x branches have removed support for the glip library and gone to using the git binary directly I do not think that it will be committed.
Comment #21
fearlsgroove commentedSo then definitely not RTBC
Comment #22
darren ohComment #23
darren ohComment #25
darren ohComment #27
dww@Darren Oh: Wow, blast from the past! This had completely fallen off my radar. Thanks for fixing it! ;)
#26 looks like you did the backport already, so removing that tag.
Thanks again,
-Derek