Decoupling Material's colors.dart

[justinmc]

I'm attempting to move a simple file with no dependencies from flutter/flutter's Material library to material_ui, in order to give us the change to test things like the batch release process, docs, etc.

I'm trying a very simple file after I was overwhelmed by ProgressIndicator in #11526.

TODOs

• Export from material_ui.dart.
• Try installing and using the package locally.
• Verify no examples to port.
• Verify that the history of colors.dart appears the same in both repos.
  • The number of commits here and in flutter/flutter's history seem similar.
  • git blame gives the same commits with new SHAs.

Open questions

• Are we sure about the directory structure?
  • What happens when a user imports material_ui.dart and there are things with the same name in both m3 and m3e?
• Anything else that should be ported along with colors.dart that I'm missing?

[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.

[stuartmorgan-g]

Is there a doc about how you are planning on doing the import? I've done quite a few history-preserving imports into flutter/packages, so I have experience with this process. I would strongly expect the import to be a single mega-PR, not a series of small PRs.

We can temporarily opt the new packages out of some checks if necessary, and then do follow-up PRs to get everything working and opt them back in.

[justinmc]

@stuartmorgan-g I'm I've been using git filter-repo which I learned about from @jtmcdole's notes on doing the engine/framework monorepo merge.

I do plan to do it via a mega PR, but before that I wanted to try landing some smaller stuff and making a prerelease to make sure that everything is working.

[stuartmorgan-g]

before that I wanted to try landing some smaller stuff and making a prerelease to make sure that everything is working.

I would very much like to avoid having multiple merge commits; each one adds permanent complexity to the repo history.

I would also advise very strongly against sliced merged commits regardless, because each one will have a distinct history, and the commits will no longer have the atomic structure that expresses what happened. We do not want N copies of hundreds of commits, each with only a subset of the actual changes, and each with a separate hash but the same description.

[justinmc]

Ah it seems you're right that multiple git filter-repo will produce multiple copies of the same flutter/flutter commit. From my other experimental decoupling PR (#11526) I see:

The first has the same SHA as the same commit on this PR, but when I ran a second git filter repo that included that commit it gave it a new SHA.

So I will close these two PRs and just go straight for the mega PR.

[stuartmorgan-g]

Ah it seems you're right that multiple git filter-repo will produce multiple copies of the same flutter/flutter commit.

Different slices of commits essentially have to create different hashes, because of the way git hashing works.