migrate issue links in source to moved issues

[pq]

I admit I don't totally know what's involved here so I'd very much welcome insights. The rub is in source we've got a handful of issue references that will need to be evaluated and updated when we migrate issues to the SDK tracker. Some are probably stale and can reasonably be deleted but in at least the case of failing tests annotated like this:

  @FailingTest(issue: 'https://github.com/dart-lang/linter/issues/3516')
  test_matchingArg_dynamicParameterToOtherArg_positional() async { ... }

I would like to preserve the context of linked issues.

@srawlins: not sure if this is an issue for dartdoc, but FYI.

Also fyi @parlough, in case you have any thoughts.

[parlough]

I just tried moving an issue between repositories, and it seems if you use GitHub's built-in transfer functionality, it preserves the issue timeline and adds a redirect from the original repository's issue link to the new location.

Perhaps a little script to run that transfer for every issue, and once transferred add the area-analyzer and analyzer-linter labels?

Then those old issue references will still work and can be revisited/updated as needed?

Edit: I'm however not sure if this persists if/when the linter is moved to the dart-archive organization, but those redirects usually work fine, so I'm assuming they will continue to work.

[srawlins]

Yeah we should just use GitHub's "Transfer issue", available with the GitHub commandline tool.

Old issue URLs are preserved as redirects to the new ones, so we don't have to clean up references. We can but we don't have to.

[srawlins]

This script looks good for bulk transfering: https://jloh.co/posts/bulk-migrate-issues-github-cli/

[pq]

Awesome! Hopefully these redirects will work even when a repo is archived? 🤞

[whesse]

I am not worried about migrating the issues. That can be done or not done.

But the issue references in the commit messages (and the pr references, in almost every commit) are of the form #1234 and implicitly refer to the current repository. So they will all change to refer to SDK issues. When merging (adding the commits to the SDK repo), I think there will be notifications on all the SDK issues that these refer to, that there is a new commit that references them.

The documentation for autolinked references is
https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/autolinked-references-and-urls

A tool that could rewrite the commit messages to expand them all to include the original repo, so #1234 would go to #1234, is

https://github.com/newren/git-filter-repo/

An example of using regexps to modify the commit message is at
https://github.com/newren/git-filter-repo/blob/main/Documentation/git-filter-repo.txt#L762

@sigurdm gave me this information.

[whesse]

We are already getting spurious notifications on old SDK issues, when a DEPS roll has a commit message that includes the titles of the commits we are rolling to.

If those commit titles, copied into the DEPS roll commit message, have PR numbers, then the SDK issue with that number gets a notification that a commit mentioning them has been uploaded, see the example at issue dart-lang/sdk#3453

[whesse]

I modified all the issue links in the linter repo to read dart-lang/linter[hash symbol]1234 instead of [hash symbol]1234, and uploaded it to https://github.com/whesse/linter . There were 2595 cases where I added dart-lang/linter, and 49 cases where the issue reference was already to a different repo. Take a look and see if it looks good to you.

[pq]

LGTM! (fyi @stereotype441)