Here's what I did according to our instructions:

HS@NB3 /d/PDev/Drupal/d8/modules/mail_edit (8.x-1.x)
$ git push -u origin 8.x-1.x
Counting objects: 19, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 372 bytes | 0 bytes/s, done.
Total 3 (delta 2), reused 0 (delta 0)
To ssh://salvis@git.drupal.org/project/mail_edit
 * [new branch]      8.x-1.x -> 8.x-1.x
Branch 8.x-1.x set up to track remote branch 8.x-1.x from origin by rebasing.

This caused two commit messages to be posted to two very old threads:

  1. https://www.drupal.org/node/792244#comment-10087786
    salvis committed 64e1e87 on 8.x-1.x
    May 18, 2010 0:19
    Commit 64e1e87 on 6.x-1.x, 8.x-1.x
  2. https://www.drupal.org/node/1238416#comment-10087788
    salvis committed f1509f8 on 8.x-1.x
    August 26, 2011 3:44
    Commit f1509f8 on 6.x-1.x, 8.x-1.x

Both are old commits in the 6.x-1.x branch of the mail_edit repository, but they are not special in any way that I can tell. Why are they popping up?

Comments

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm at Drupal Association commented
Status: Active » Closed (works as designed)

While this is an edge case, it is normal behavior. The commits reference those issues, and the issues are open. Pushing commits to a new branch is usually significant, and should get comments.

salvis’s picture

salvis
he/his
CreditAttribution: salvis commented
Status: Closed (works as designed) » Active

How does the new commit (only one!) reference either of those issues?

I can see that #792244-35: Add !username_themed; replace Subscriptions' *_realname? mentions "#792244: Add !username_themed variable.", but WHY? It links to the old commit. Why do we suddenly need to know that there was a commit five years ago?

The new commit's message is "Open new 8.x-1.x branch.", and no, it doesn't mention any issue number. Why does it trigger commit messages on two completely unrelated issues.

The old commit with the "#792244: Add !username_themed variable." message was pushed with #792244-28: Add !username_themed; replace Subscriptions' *_realname? five years ago on 2010-05-17 22:19:52 (GMT)!

Why did the 8.x-1.x bit pop up in the old commit message (see below), apparently due to a new commit that is completely unrelated?

    May 18, 2010 0:19
    Commit 64e1e87 on 6.x-1.x, 8.x-1.x      <======= What does this mean? 
    by salvis                  ^^^^^^^
    mail_edit: /mail_edit_user.inc
    ++

    #792244: Add !username_themed variable.

How can 5-year-old commit 64e1e87 appear on the 8.x-1.x branch that I created only a few days ago. Of course it's part of 8.x-1.x's history, but so are lots of others, and we surely don't list them all...

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm at Drupal Association commented

How can 5-year-old commit 64e1e87 appear on the 8.x-1.x branch that I created only a few days ago. Of course it's part of 8.x-1.x's history

Git doesn't really make this distinction, the branch is simply a pointer to the commit at the tip of the branch. As far as I'm aware, there isn't a history of which branch each commit was originally committed to, or if it was merged in. The merge's commit message can have some details, but not in a machine readable format. The pointers parent commits are only that, no information about branches.

Think of this as adding a commit to a branch.

The new commit's message is "Open new 8.x-1.x branch.", and no, it doesn't mention any issue number. Why does it trigger commit messages on two completely unrelated issues.

The history of commits are what triggered this. The commits were added to the new branch, and referenced issues that are still open. Commit comments are made when:

  • The commit mentions an open issue.
  • And the commit is on a release branch or the branch name also contains the issue number.
salvis’s picture

salvis
he/his
CreditAttribution: salvis commented
Status: Active » Closed (works as designed)

the branch is simply a pointer to the commit at the tip of the branch. As far as I'm aware, there isn't a history of which branch each commit was originally committed to, or if it was merged in.

Yes, but why are any commits other than the new commit candidates for commit messages? Is this to catch commits from merged branches? And it relies on keeping the issue open as long as the feature branch is not merged into a release branch? That's kind of neat but also a bit obscure.

So, when a new commit is made, all old commits in the history of the branch are scanned, and if any old commits reference an open issue (any open issue) then those issues get a commit message? I think we should check the parent commit and ignore commits that are already in the history of the parent commit.

Think of this as adding a commit to a branch.

By creating a new branch, we're adding all the commits in its history to it? That's stretching it a bit, but yeah, you can see it that way. Did the creation of the new branch trigger the odd commit messages, or the pushing of the new commit in the new branch? If someone re-opens another D6 issue with a commit, and I push a D8 commit, will the unrelated D6 issue get a new commit message, too?

If you say it's WAD then I won't insist any further.

Thanks for looking into it.

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm at Drupal Association commented

Yes, but why are any commits other than the new commit candidates for commit messages? Is this to catch commits from merged branches? And it relies on keeping the issue open as long as the feature branch is not merged into a release branch?

Yes, that is what we've settled on for now.

So, when a new commit is made, all old commits in the history of the branch are scanned, and if any old commits reference an open issue (any open issue) then those issues get a commit message? I think we should check the parent commit and ignore commits that are already in the history of the parent commit.

At the moment, the Version Control Git module doesn't remember what commits it has seen and where. A push can contain multiple totally new commits.

Did the creation of the new branch trigger the odd commit messages, or the pushing of the new commit in the new branch?

Pushing the new branch was the trigger. (The new commit may have been part of the same git push.)

If someone re-opens another D6 issue with a commit, and I push a D8 commit, will the unrelated D6 issue get a new commit message, too?

No, those have been pushed to the branch and won't be part of another push.

salvis’s picture

salvis
he/his
CreditAttribution: salvis commented

Thanks, drumm, good to know the details!