Commit backlink incorrectly appears when commit made to new branch

Here an untested patch to filter the relevant refs(branches) for the message.

It seems to be working mostly correctly: adding a comment when new code is added to a branch, that includes the case when some old code in a topic branch is added to a release branch and then pushed(which sounds like your mentioned case).

About the date, it uses current date, which should be around git push date(aka git event date), and it does not try to get the exact push date to avoid incoherences in the comment list(i.e. the auto-comment is processed after someone adds a new comment, but its push date is before that).

For now, it may suffice to check if the Git Branch the commit belongs to matches the branch associated with the issue version.

Sorry, I would say this part is a won't fix, since I would like to avoid checking version strings(i.e. missing a commit message because someone change the issue version incorrectly), I think it is OK to trust on committers to add relevant messages when needed.

Still not tested.

What's new: Do not make comments on closed issues. (because the duplicate issue, #2236297: Creating a new branch seems to update all tickets with old commits, that points at that)

Looks like an okay approach. I agree we shouldn't strictly check versions, seeing the commits on feature branches, and when something is quickly fixed in multiple branches is a good thing. A couple improvements:

      if ($possible_issue->field_issue_status[LANGUAGE_NONE][0]['value'] = PROJECT_ISSUE_STATE_CLOSED) {

Use ==, or === if possible.

The new functions need doc comments.

So it appears git push auto-comments are being added to issues for all commits ever?

I have to say, I find the date inconsistency very problematic. For one, it notifies all subscribers that a new commit has happened, although that in fact is not the case (it may be years old). Secondly, it gives a wrong historical view of the issue thread, since commit comments will be out-of-place chronologically.

@marvil07: I don't quite follow your reasoning in #2 about why it's bad to retrieve the exact push-date and use that as the comment date? I imagine the comment numbering might become an issue, but something similar was solved previously using sub-numbering (#05-1, #321-4 etc) AFAIR.

Here are a couple of examples of auto-commit comments generated for year-old commits:

• https://drupal.org/node/1777818#comment-8792403
• https://drupal.org/node/1736474#comment-8804965

The first chunk is working well on dev. I changed it to use ==.

The rest will need to be tested on git7site, since it needs to receive commits as they are pushed.

This is an improvement, but not sure if it is solved yet.

Before, a push with a new branch had:

drumm committed 5922d7e on 7.x-1.x, test-branch-1

After:

drumm committed 5922d7e on test-branch-2

This is not showing the extra 7.x-1.x branch again, as designed.

I think this is okay. It is certainly an improvement and good to deploy.

We still have the case of seemingly-extra comments when a new branch is created, for issues that are not Closed (fixed), but there isn't currently a great programmatic way of knowing what's part of a branching strategy where the comments are useful, and what isn't.

Now deployed on Drupal.org.

For my understanding: should this fix existing auto-comments, or does it only apply to new ones?

Only new ones.

Existing comments wouldn't be straightforward - querying all comments for system message comments, parsing labels and commit IDs out of the HTML, and writing an algorithm to find the ones to delete. I think time would be better spent elsewhere.

https://www.drupal.org/node/1828512#comment-8954277 was just added 3 days ago. It's for a commit that happened 2012-10-31, but now the commit is saying it was committed to a new branch (2299191-beta_project_issue_project_searchapi -- presumably recently pushed). It seems like something about this fix didn't completely solve the problem. Apologies for not tearing into all the patches and code to figure out what's going on, but I wanted to report the problem in case the folks more familiar with this commit/comment functionality can quickly make sense of this case.

Thanks,
-Derek

@dww: the mentioned link is working as expected. The commit message refers to the issue, the issue is not closed state and the commit was added in a new push containing it. So, it adds a comment.
Sadly that's current behavior. I guess this can be extended more to i.e. do not add a comment when issue is in postponed state, but I'm not sure that's what we want(i.e. someone adds relevant code and other people want to know about it).

In any case, marking again as fixed, since this was a good initial step. Let's discuss about new features in a different issue.

I'll be adding a couple of follow ups soon.

New on last two commits:

• generalize a little to extend base git event processor class in an easier way, also do not associate the issue only on comments event processor, but not on general issue mapper.
• use all non-open(project issue module defines an "open states" variable) instead of one of them declared in a constant(we were ignoring only "Closed (fixed)" status).

Back to fixed.

Adding tag, currently d.o has 7.x-1.0-rc1+29-dev (based on git7site), and current version with these commits is 7.x-1.0-rc1-32-g9e5b3fe.

This was deployed yesterday: https://bitbucket.org/drupalorg-infrastructure/drupal.org/commits/04a08c...