Increase cloning depth for a companion merge #16
Conversation
|
Fixes this. |
|
@rcny what was the thought process or reasoning for this change? Only the HEAD code is used for the integration, so cloning more of the history should not matter for anything. |
|
@joao-paulo-parity we now merge master into the companion and the local branch. That required this. |
@bkchr what is the point of bringing in master's code before the check? The master you merge at the time the check is ran is not guaranteed to be representative of how master is at the time the merge is done. I'm guessing there is a reason why it is necessary in some cases, but I could not find an explanation. The script used to only consider the code in the current branch, therefore one would be able reason about why it failed exactly. By bringing in the master's code at the time the check runs you get rid of this predictability. That detail might not be relevant anyways, but if the behavior is changed, it should have been motivated with a comment in the code. I found #10 (comment) but it does not explain why it is necessary. |
|
Let's assume you have a pr that doesn't require any companion. It builds fine with Polkadot, however in the mean time someone merged a breaking change. You will try to compile with Polkadot master, but that will fail because you don't have the required Substrate changes in your branch. Merging master into the Polkadot companion makes it easier for you when you have merged master into your Substrate branch, because you don't need to update the Polkadot companion. |
No description provided.