Is it safe to use experimental_custom_rev_id ?

[AlexTrotsenko]

I see, that reference documentation about experimental_custom_rev_id contains following warning:

Use this label name instead of the one provided by the origin. This is subject to change and there is no guarantee.

We are planning to have monorepo with at least two public SDK.

I was thinking of using experimental_custom_rev_id In order to avoid collisions of syncing git commits from these two public repo.

Also having SDK1_REV_ID and SDK2_REV_ID in git commit makes such commits cleaner to us as well.

I am wondered if it's "safe" to use this property since it's explicitly marked as experimental? If it will change - will you provide a migration path for existing repo, which use copybara with this property?

Btw, I see the advice from @mikelalcon to use experimental_custom_rev_id yet in 2019 - is there is any reason why it's still considered experimental?
#84 (comment)

[hsudhof]

Yes, this works, except some corner cases that generally don't affect git.

[mikelalcon]

Alex, I'm sending a change to promote the field out of experimental. This has been stable for some time and we are confident to keep it.

[AlexTrotsenko]

Thanks for your quick reply with update and taking care of promoting it to stable!

May I possibly ask one more question relation to the format of "rev id", which I am curious about?
I see, that currently it's required to use format like CUSTOM_REV_ID, while for copybara itself I see commits with something like PiperOrigin-RevId.

Is it some sort of the old format or ?

[mikelalcon]

Yeah, initially we used FooOrigin-RevId, but then that was a problem for some internal system. We kept that one with a hack converter (GitOrigin-RevId is converted to GIT_ORIGIN_REV_ID internally). So when I added the custom rev-id I forced to the new format.

[AlexTrotsenko]

@mikelalcon thanks for the information.
I assume, that it's also a reason why default label, which is currently added by copybara is GitOrigin-RevId and not GIT_ORIGIN_REV_ID, right :) ?