| Project: | Version Control / Project* integration |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | git phase 3 |
Issue Summary
Problem/Motivation
Many issues don't have patches in the comments if they are fixed by the author, so it's sometimes inconvenient to find the actual code change.
Some issues have follow-ups or authors just think it make sense to add iterative changes over one issue. This means more than one commit per issue. Notice some issue can have a lot of patches, so it could be tricky to find the ones applied to upstream.
Proposed resolution
Show a list of commits(versioncontrol operations) related with the issue.
Implement it as a new submodule.
Remaining tasks
Still needed:
- Add initialization of values(maybe a drush command? e.g. project repositories with lots of operations can take a while).
- Change the mappings when a project issue is changed of project.
- Design UI to show the operations(now it simply load the operation objects on $node->project_issue['operations']).
- Decide if we want to make message parsing a ctools plugin? (sounds like a good idea instead of hardcoding a regex).
User interface changes
- Project issues will have one new element showing the list of its related commits.
API changes
None.
Original report by grendzy
It would be cool if, in addition to the node id filter [#NNN], we could also link to a CVS commit message the same way.
Many issues don't have patches in the comments if they are fixed by the author, so it's sometimes inconvenient to find the actual code change.
I also keep seeing module author's fix and close an issue in CVS, and the the issues gets a deluge of comments like "it still doesn't work! How come there's no new release today?" Making it easier for module authors to say "fixed in [r:NNN]" instead of just "fixed" might help clarify things for beginners.
Thanks!
Comments
#1
What you propose won't necessarily help with this problem, because the maintainer would still need to post the commit id in a comment when setting the status to fixed.
What you probably were thinking of (which should IMO be a separate issue) would be a way for an issue to automatically have links somewhere to all commits in which that issue was mentioned. That'd be a nice feature to have, though would be more complicated to write. Maybe someone has already suggested that, but I don't remember hearing such a suggestion.
#2
Also, I'm almost certain that this issue is a duplicate (I think moshe was the one who originally requested this), but I can't find the original issue in the cvslog or project_issue module queue.
Another issue that is slightly related to this one is #132694: add a UI to filter the views of commit messages. From the last link in that original issue, I see what I said in #1 about linking to all commit messages which refer to an issue is already possible. We'd just need to automatically add a link somewhere on the issue node itself.
#3
The way you described it, yes that would probably be more useful. Though I've used systems that allow links to be created in either side, putting the issue number in the commit message and then automatically displaying it is probably ideal.
Should this suggestion be in a different queue?
#4
#5
Yeah, I probably submitted an issue about this ages ago. ;) It's been on my wish-list for a long time. I was just talking about this again over at #433050-2: Add code to parse and aggregate CVS contributor info in fact...
I think this code should live in the CVS Integration module, not project_issue... I mean, ideally, it should live in versioncontrol_project or something. ;) But, until that's ready for prime time, let's call this a CVS integration issue.
#6
If you want to see this on d.o, you should followup over at #493074: Back-link to the commit as a comment on the related issue.*
*Not technically a duplicate of this issue :(
#7
sub, working on issue in #6.
#8
Moving to versioncontrol_project, hoping nobody here still wants this for CVS intergration, if so please move it back and I will open another one for it. But I guess this started as a drupal.org feature, so I guess it's OK to move it.
Some complementary comments can be found on the related issue #493074: Back-link to the commit as a comment on the related issue. (see comments #25, #26)
#9
I have been taking a look at this. It lacks of auto-initialization of values on hook_enable, and it really needs a test(I just wrote what I was thinking), but it's a start.
#10
After some minor fixes, this is working locally :-).
Still needed:
$node->project_issue['operations']).To decide:
#11
tagging