There are two files A and B. One is edited in branch b1. Both were edited in branch b2.
When merging b1 to b2, I am resolving the conflict by deciding that version of file A from branch b1 is correct. However, after the merge, file B doesn't match file A, since B was never edited on branch b1 (file B keeps commits from b2 without any conflicts).
I want to somehow mark file B as edited on b1 in this case, because I know that when file A is changed, then the file B must also follow, even if its content didn't change. (One could say B was edited on b1, but the result of the edit is "no changes").
How to do that? I know about custom merge drivers or setting merge attribute for the file, but those work only if the file has conflict. There is no conflict on file B, there is only an "inconsistency" between A and B. I also found "assume-unchanged" setting, but it seems there is no "assume-changed" option.
There's no way to do this. When you have a normal merge, Git considers exactly three points, the two heads (branches) and a third point, called the merge base, which is usually the most recent common ancestor.
If you perform a merge and both sides have the same blob, then that value is taken. If exactly one side has a change and the other has the same blob as the merge base, then Git adopts that change without invoking any more complicated merge machinery. There's simply no way to make Git cause a conflict here if there isn't one already.
It sounds like what you're doing might be to check in some sort of generated file. If so, don't do that; generate it as part of your build process, which is the simple and easy way to make this work.
If that's not the case, and you're already resolving a conflict, you can make edits to other files that haven't conflicted at the same time as part of the merge commit. You may want to create a CI job that fails if the two files aren't in sync so if someone does a merge by hand that they can't leave things in an inconsistent state.