[DatePicker] Migrate to the lab

[dmtrKovalenko]

• I have followed (at least) the PR section of the contributing guide.

This PR must not be squashed because we will lose all the git history

Edit Olivier: I was aiming to keep all the history of v4, starting with the first commit. However, this has proven to be very challenging to handle (I couldn't figure out how while resolving the merge conflicts). So instead, we have a single commit with Dmitiry as the original author. I think that it's good enough as we will likely still iterate a lot on the logic.

Closes #19706

TODO Olivier:

• Filter regressions test that is not needed
• Preliminary TypeScript component infrastructure [lab] Migrate Timeline to TypeScript #23242
• Add ⚡️ section for date range picker
• Solve Netlify build performance issue, we have reached the limit of pages we can have. Contacted support, increase limits from 15 to 30 minutes

[eps1lon]

Looks good since I see a lot of commits 👍 Now we just have to hope the git surgery goes smoothly

[mbrookes]

Scalpel. Forceps...

[eps1lon]

Includes all commits from pickers, one commit from git-subtree-add and one commit for integration squashed the work done in #22692

[eps1lon]

DONT SQUASH AND MERGE THIS

Once this is green and approved I enable merge commits in this repo and merge it with git merge

[oliviertassinari]

This looks almost good. I think that the only part left is to trim pre v4 git history:

The argument in favor of only keep v4: the work on-pre v4 isn't relevant. We have reworked significant parts of the logic and will keep doing so. We don't need to go back in the history. This history can be still found on material-ui-pickers, the repository will be archived and accessible indefinitely.

[eps1lon]

The argument in favor of only keep v4: the work on-pre v4 isn't relevant.

Every git history is relevant. We don't actually want to discuss whether git is relevant. Let's move forward.

[oliviertassinari]

@eps1lon Ok, I think that @mbrookes can settle the matter. I think that it would be better by truncating the history, but no strong point of view. So happy to go in the other direction if it gets broader approval.

[eps1lon]

Ok, I think that @mbrookes can settle the matter. I think that it would be better by truncating the history, but no strong point of view.

Could you explain to me what changed in the last few days between me saying I restore the history and now where you're saying we don't need it?

[oliviertassinari]

@eps1lon I have tried to mention it a couple of days ago by updating the pull request description:

and in #22692 (comment) before we start doing the rebase, I think that it's complementary :). I guess "first commit" was confusing, it was pointing to the first commit of v4.

[mbrookes]

@oliviertassinari I don't see any arguments made against keeping the pre-v4 history, only that keeping even the v4 history was proving challenging. If @eps1lon has solved that (quite how, we may never know! 😄), what's the concern?

[oliviertassinari]

The argument for only keeping v4 onward (about a year of history) is to avoid to include history that we won't be able to leverage. What's the overhead of storing a large git tree? (time to clone, etc?).

[mbrookes]

What's the overhead of storing a large git tree?

Google seem to manage. Do you have some metrics to demonstrate a problem?

[eps1lon]

(quite how, we may never know! smile)

1. start with up-to-date next
2. git-subtree-add
3. git-cherry-pick each actual "compat commit" from this PR
4. squash "compat commits"

I thought I could just re-order these compat commits with git-rebase but the visual tool I was using didn't offer that (GitKraken). Moving them via command line sounded too error-prine to me and then I would still have to convert merge commits. Still an interesting exercise but cherry-picking was sufficient here.

[eps1lon]

What's the overhead of storing a large git tree?

Any potential problem that would arise from 2000 new commits we would have in a year anyway.