Merge graphs package

[dcharkes]

Do NOT squash merge!

Reasons for merging into dart-lang/tools mono_repo:

• Easier maintenance.
• Automatic mirroring in https://dart.googlesource.com/tools instead of setting up a new mirror for graphs.

Steps taken:

1. Get git-filter-repo:
   newren $ git clone git@github.com:newren/git-filter-repo.git
2. Add git-filter-repo to PATH.
3. Fresh clone of repo that needs to be merged into a mono repo:
   dart-lang $ git clone git@github.com:dart-lang/graphs.git
4. Destructively rewrite the history of the repository to be in pkgs/package_name:
   graphs $ git filter-repo --path-rename :pkgs/graphs/
5. Destructively prefix all the tags:
   graphs $ git filter-repo --tag-rename :graphs-
6. Replace paths and links in files.
   1. Badges: https://github.com/dart-lang/graphs/actions/workflows/ci.yml -> https://github.com/dart-lang/tools/actions/workflows/graphs.yml
   2. Remaining links, manually check if this does the right thing, otherwise insert steps above this step. https://github.com/dart-lang/graphs -> https://github.com/dart-lang/tools/tree/main/pkgs/graphs
7. Migrate the GitHub workflow.
   1. Delete dependabot.yaml which is already in the target mono_repo.
   2. Rename file: pkgs/graphs/.github/workflows/ci.yml -> .github/workflows/graphs.yml
   3. Add paths to the on clauses in the GitHub workflow (example).
   4. Add defaults->run->working-directory to all jobs in the GitHub workflow (example).
8. Commit with a detailed message.
9. In the directory of the mono_repo, create a branch.
   tools $ git checkout -b merge-graphs-package
10. Add a remote for the local clone of the moving package
    1. tools $ git remote add graphs_package /Users/dacoharkes/src/dart-lang/graphs/
    2. tools $ git fetch graphs_package
11. Merge
    tools $ git merge --allow-unrelated-histories graphs_package/master -m "Merge package:graphs into shared tool repository"
12. Copy the list of renamed tags into a comment on the PR.

Current step:

13. Create a pull request and get it reviewed. Do not submit through the github UI, since it does not allow a fast forward merge.
    1. If there are changes required, back out and start over (it's OK to force push to the PR branch)

Steps to do:

14. Disable squash-only in GitHub settings, and merge with a fast forward merge to the main branch, enable squash-only in GitHub settings.
15. Push tags to github
16. Follow up with a PR adding links to the top-level readme table.
17. Add a commit to https://github.com/dart-lang/graphs/ with it's readme pointing to this repo
18. Archive https://github.com/dart-lang/graphs/.

Tag names after renaming:

• [new tag] graphs-v0.1.0 -> graphs-v0.1.0
• [new tag] graphs-v0.1.1 -> graphs-v0.1.1
• [new tag] graphs-v0.1.2 -> graphs-v0.1.2
• [new tag] graphs-v0.1.2+1 -> graphs-v0.1.2+1
• [new tag] graphs-v0.1.3 -> graphs-v0.1.3
• [new tag] graphs-v0.1.3+1 -> graphs-v0.1.3+1
• [new tag] graphs-v0.2.0 -> graphs-v0.2.0
• [new tag] graphs-v1.0.0 -> graphs-v1.0.0
• [new tag] graphs-v2.0.0 -> graphs-v2.0.0
• [new tag] graphs-v2.1.0 -> graphs-v2.1.0
• [new tag] graphs-v2.2.0 -> graphs-v2.2.0

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[github-actions]

Package publishing

Package	Version	Status	Publish tag (post-merge)
package:unified_analytics	1.1.1	ready to publish	unified_analytics-v1.1.1
package:cli_config	0.1.1	already published at pub.dev
package:graphs	2.3.0	already published at pub.dev

Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation.

[devoncarew]

lgtm for my part

(generally, I wonder if there's any way we can make very very sure that these package-merge PRs don't accidentally get merged in through the github UI)

[devoncarew]

Not necessary for this PR (can be done after its merged in), but we can delete this separate contributing file.

[devoncarew]

Anytime we make changes to the pubspec file we really should rev the version. Generally, I'd say that we should merge this in unchanged, and then plan to come along later w/ a PR to the tools/ repo that updates this to the correct value and revs the pubspec version.

No concerns however w/o merging this in as is, we should just plan to rev the pubspec after the merge).

[dcharkes]

generally, I wonder if there's any way we can make very very sure that these package-merge PRs don't accidentally get merged in through the github UI

I have followed @stuartmorgan's suggestion on the doc to enable merge commits in the repo settings, then merge in the GitHub UI, and then turn that setting off again in the repo setings.

The result is two merge commits, one from the git merge of the two repos, one from GitHub itself, it doesn't do fast forward:

If I would have pushed to main instead, then main would now be at 4331e28.

This seems to have no effect on git blame etc.