Since the only viable solution is to track the file ‘f
‘ at all times, you could add, only in branch B
, a smudge/clean process with a gitattributes filter driver:
When checkouting branch B
:
-
the smudge process would change:
- save the content of
f
in a temp file - replace the content of
f
with onefbis
file (a tracked file which would contain, for branchB
, the “B
content off
“)
- save the content of
-
the clean process would:
- save
f
content (as modified inB
) infbis
(fbis
gets committed withf
modifications in branchB
) - restore
f
content (with the temp file), meaningf
is not committed (ignored inB
)
- save
You can add, still in branch B
, a custom merge driver which will protect fbis
in case of merges from other branches to B
:
the merge driver will always keep B
version of fbis
content, making sure the ignored file f
gets back its content whenever branch B
is checked-out.
Since those drivers (filter and merge) are not committed in other branches, the file ‘f’ is committed in other branches with all its modifications.
In branch B
, its content will never change, and yet the “local modifications” made to f
are still restored whenever B
is checked-out.
If that content restoration is not needed, you don’t need to manage fbis
.
Just keep the filter driver and you will be sure that whatever modification you do to f
in branch B
, those changes will never be committed, effectively ignoring f
content.