Test plan checks out and rationale makes sense.

So we are looking to do this because maintaining this rebase conflict is worth the trouble as it allows us to preserve the repo's history? imo also probably worthwhile...otherwise would have to deprecate the current repo and create a new mirror one.

A couple of nits:

1. Is there any way to fix the conflict by changing something in the remote repo (without wiping or deprecating it for a new one)?
2. Are we sure that the first conflict will always be this exact expected one?

In D14384#322528, @bytesofman wrote:

Test plan checks out and rationale makes sense.

So we are looking to do this because maintaining this rebase conflict is worth the trouble as it allows us to preserve the repo's history? imo also probably worthwhile...otherwise would have to deprecate the current repo and create a new mirror one.

A couple of nits:

1. Is there any way to fix the conflict by changing something in the remote repo (without wiping or deprecating it for a new one)?
2. Are we sure that the first conflict will always be this exact expected one?

Yes, the idea is that we want to preserve the repo's history so we have a way to use git blame, find old commit message to figure out how some piece of code evolved, keep an archive of the list of authors and their contributions...

I tried changing the remote repo to have it be exactly identical to the monorepo , and that fixed the script for its first run, but unfortunately I could not figure out any way to make that commit then not conflict with itself on subsequent runs. Another thing I tried is to define a merge strategy to keep "our" or "theirs" changes in case of a conflict, but this also only worked once. On subsequent runs the initial monorepo integration commit would revert itself, not matter what strategy I chose. It seems like copying the content of a repo into a monorepo makes it forever un-rebasable on the origin repo, unless the first commit is somehow skipped.

I'm reasonably sure that the first conflict will always be the same, as it is the very first commit in the monorepo's history conflicting with its remote counterpart.

Note that if this fails for some reason, it can only break the archive / mirror (which could then be reset to its original state with a git reset --hard ... command). It will not affect the monorepo. So the damage will be limited.

The only alternatives I can think of are:

• always reset the remote repo to its initial state (pre-monorepo) before rebasing the monorepo history
• apply only the recent/new commits as patches instead of rebase

Both of these alternatives are more complex (especially the second one which would require to detect what it the latest monorepo commit that is already applied in the archive).