Initial import of existing repo and ITERATIVE mode usage question

We are currently migrating some existing repos to the new monorepo structure while keeping access to some of them accessible for the wider audience.

In order to keep all the git history of the individual "public" repo we have used "ITERATIVE" mode for initial migration to the "private" monorepo.

Afterwards we have set-up workflow with "ITERATIVE" mode for private->public (as advised in the https://github.com/google/copybara/issues/24#issuecomment-324925392 )

However since we use bitbucket and gitlab we can't use `CHANGE_REQUEST` mode - so our initial idea was to keep "ITERATIVE" mode for "public" -> "private" workflow (same as it was during the initial migration).

And we have discovered an interesting behaviour:
- if only 1 commit is migrated from "public" to "private" and back to "public" - copybara is able to detect, that it's the same commit and does nothing.
- but if there are at least 2 commits -> those commits are added back to "public" repo and are "duplicated" on top of existing commits _(so this can results in the loop if public->private and private->public migrations are run one after another)_.

The same time If we use "SQUASH" for "public" - > "private" workflow - then copybara is able to detect empty change with any number of commits.

interestingly enough, I have noticed, that if we enable `metadata.squash_notes()` and commit _new change_ to "private" - these commits are actually also present in the "squash" commit details along with _new change_ commit.

May I possibly ask you for the intended use/set-up of copybara for the case when public repo should be "imported" at first to monorepo and repos are not github repos?

Perhaps I am missing something and copybara can use `GitOrigin-RevId` of the "public" commit once they are migrated back to "public" and just skip it ?