7/25/2023 0 Comments Gitx devWhere “ *” can be any substring not containing slash(/) or forbidden character. This would allow to use masks in the branch rules like: if this commit is reached from 'feature-*' branch in parent, then the module should follow 'some-*' branch in the module repository ![]() We plan to extend the UI to edit the rules more explicitly. These branch rules may seem to be an overcomplication, but they are not. Then the synchronization is enabled again. ‘main’ branch in the module repository), you’ll implicitly add the rule: if this commit is reached from 'feature' branch in parent, then the module should follow 'main' branch in the module repository But if you edit the “Module Location” in the UI to specify to some branch (e.g. When no rule is applicable, no synchronization happens. Once you created a feature branch, the same setting became not applicable because “if this commit is reached from ‘main’ branch” is not true in the feature branch. This rule was applicable when you had ‘main’ branch in the parent. Originally when ‘main’ branch in the parent repository had a module tracking ‘main’ branch in the module repository, you had the following settings: if this commit is reached from 'main' branch in parent, then the module should follow 'main' branch in the module repository Or if this commit is reached from branch X, then the module should be fixed to commit with that SHA-1 The module rules look like if this commit is reached from branch X, then the module should follow branch Y in repository Z each commit in the parent repository has its own settings) contain something that we call “module rules”. Internally, the module settings (they are per commit, i.e. In other words, they will become in sync again. to the main branch of the module repository, the module will receive newer commits from the module repository (if there’re any) and follow the module’s branch. Once you change this branch to some branch, e.g. This means that the module in this branch points to a fixed commit. If you open your parent repository page on v and switch the branch to the feature branch and pay attention to “Module Location” section, you’ll see that the branch is not selected there. ![]() That’s why we decided to make it the user’s responsibility to apply the newer module commits manually. It’s very likely that they would be inconsistent with the parent content, leading to compilation errors. Otherwise, if you would checkout a new branch from older commit and v were set up the module branch, it would then apply all the newer module commits since that older state. This is because usually when someone checks out a new branch, especially not from the latest commit but from some older commit, the user expects this new branch to be a snapshot of that commit. It stays in this state until you explicitly set it up to follow some branch. pegged to a specific module commit instead of tracking the module branch. When you checkout a feature branch off the parent main branch, the module in it becomes fixed, i.e.
0 Comments
Leave a Reply. |