What happens to exclusions during a merge?

Hi Mark, thanks for your quick reply. I don't want a reciprocal merge: I want the changes of DEV merged into REL, not vice versa. Is that possible?

I want the changes of DEV merged into REL, not vice versa. Is that possible?

Certainly, the DEV branch may not be protected in that case. Then you will be able to perform a merge from DEV to REL and Archive the branch after the merge session, or Finalize it and declare the branch definitive at that point.

To essentially close the branch, no other branches may exist that have DEV as their Origin; or in other words, branches that have been made from DEV. Only then, the Protected state can be turned off in Model overview > Branches by editing the record.

It is not possible to only merge changes from one branch to another without closing the Source branch or update it by the reciprocal merge, only in case of an Arbitrary branch that would be possible,

Info on these:
https://docs.thinkwisesoftware.com/docs/sf/branches#protect-a-branch

https://docs.thinkwisesoftware.com/docs/sf/merging#1-create-a-merge-session

https://docs.thinkwisesoftware.com/blog/2024_2#models---merge-changes-into-an-arbitrary-branch

Hi ​@wallytax,

Was Mark’s response sufficient to answer your question?

Hi ​@Jeroen van den Belt,

Thanks for asking, but I don't think I understand the branching mechanism, because it seems to be very different from what I am used to (GIT).

Mark mentions the protection of the branch. But if I understand it correctly that only applies to which users may make changes into which branch. I am not sure if this has to do with the data being reverted to its old state when excluding certain changes.

The part about the branches being reciprocal is a new concept for me and I don't know if it's possible to change that setting, unless it's the same as the "protected” setting, but I don't think it is.

Back to the main problem - which for me is a common situation - I have “accidentally” changed multiple things that actually needed to be in their own branch. I only want to merge a couple of changes in the DEVELOPMENT branch to the RELEASE branch and therefore I revert the other changes. After that those excluded changes are gone. Now I created a new branch originating from DEVELOPMENT and again made a little bit too many changes in it so I only want to merge a couple of changes to DEVELOPMENT, but I don't dare to since I will probably be loosing the other changes.

But I start to repeat myself, so I think I should be very keen on make the right changes in the right branch.

Hi ​@wallytax,

I think the missing piece is what “protected” means, so let me start there.

Protecting a branch is not about who may change it. That is branch access, which is a separate setting. A protected branch cannot be archived or deleted, and a branch becomes protected automatically as soon as another branch uses it as its origin (Protect a branch). When the source branch of a merge is protected, the only option is Keep working in branch, perform reciprocal merge (Create a merge session). So “reciprocal” is not a separate setting you can switch off. Once you created a branch from DEVELOPMENT, every merge from DEVELOPMENT is a reciprocal one.

A reciprocal merge brings your changes into the target and the target’s changes into your branch, so that afterwards both branches are the same. An excluded change cannot stay behind as “not merged yet” in that situation. Your branch is brought in line with the target, which is why your excluded line was replaced by the RELEASE version. This is where it differs from Git.

Your new branch is different, as long as no other branch has been created from it. It is then not protected, so when you merge it into DEVELOPMENT you can choose Finalize branch instead of a reciprocal merge. With Finalize, the actions you exclude are not reverted. They stay in your branch, which becomes read-only and is kept for reference (Create a merge session). A finalized branch cannot be merged again, so you redo the excluded changes in a new branch created from DEVELOPMENT. Choose Finalize rather than Archive here: archiving deletes the branch’s data, so you would lose the excluded changes after all (Archive a branch).

If you need the code that was reverted in your earlier merge, you can still get to it. Create a new branch from DEVELOPMENT at a point in time before that merge (Create a new branch). That branch shows the model as it was then, so you can look up the excluded changes and redo them in a branch of their own. Use it to look things up, not to merge back.

Going forward, your own conclusion is still the easiest one: keep each set of changes in its own branch, so you can always merge a branch as a whole.

Setting changes aside in a branch you keep working in, as you would with Git stash, is not possible today. There is an open idea for it, Ability to stash branch changes, which you can vote on.

This part is not really clear to me. For which branch(es) is the merge reciprocal? The branch with its origin set to DEVELOPMENT?

I've tried to read carefully the rest of the post as well and I hope I will figure out more of how it works during the usage of ThinkWise. I can't really get it right in my head from reading your message, but I do appreciate your attempt to explain it. 😀

Once you create a branch (B) from another branch (A), branch A becomes protected - which simply means it cannot be removed or archived.

If you perform a merge session from B to A, you can choose to perform a Reciprocal merge. This will merge all changes from B to A and vice-versa. Any excluded actions will be reverted/removed/gone from both branches. You may continue working in branch B.

A merge between two protected branches will always be a reciprocal merge - typically MAIN to a child branch like RELEASE.

With that first example, B can be merged into A without a reciprocal merge, but then branch B will either be Archived or Finalized.

Hope that clears it up 😄

Yes Mark, that clears things up! Thanks for you quick response!