We will allow changes to submodules in the VMR. Those will be done by the darc vmr reset-submodule
In forward flows, right now, we look at the changes to the submodules in the original repo. Then we create patches for that diff and apply them on the VMR. Up till now, we did not expect problems there, because the VMR submodules never changed in the VMR only. Now that this is changing, we must be able to support such case.
Technically, this is might be a conflict case - both the repo and the VMR had a change to their submodules - so we won't be able to decide which one should apply.
- In case the submodule in the repo got rewound to the same SHA that the VMR, we can just no-op as no change is required. Currently, this is also not supported but should be.
- In case we have different SHAs, we should trigger the conflict flow from the service. In darc, we'd just ignore the submodule change but error out and tell the user that this is the situation. In most cases, this means the VMR had a submodule change the repo does not know about and needs to backflow. Or it's a real conflict. Or the user can resolve it by using
darc vmr reset-submodule (maybe the error can mention that too as a remediation and then the two various SHAs that are conflicting).
We will allow changes to submodules in the VMR. Those will be done by the
darc vmr reset-submoduleIn forward flows, right now, we look at the changes to the submodules in the original repo. Then we create patches for that diff and apply them on the VMR. Up till now, we did not expect problems there, because the VMR submodules never changed in the VMR only. Now that this is changing, we must be able to support such case.
Technically, this is might be a conflict case - both the repo and the VMR had a change to their submodules - so we won't be able to decide which one should apply.
darc vmr reset-submodule(maybe the error can mention that too as a remediation and then the two various SHAs that are conflicting).