You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a .swift-format file at the root of my repo, but some third-party code in a sub-directory. I'd like to be able to disable formatting for the subdirectory.
There are a couple of ways that this could be accomplished
a setting in .swift-format with a pattern or patterns for paths to be excluded from formatting
detecting the presence of a file .no-swift-format and disabling formatting anywhere below that file in the tree
The former case is useful, but would not be sufficient in the situation where you've a submodule with some third-party code, and that submodule has its own .swift-format file. In that situation the module's file would take precedence as it is closest, but you'd want to be able to override it locally without having to make changes to it.
Detecting a .no-swift-format file at the same level would be efficient in this situation, and the file could be added to .gitignore for the module, so that creating it locally would not cause upstream problems.
The text was updated successfully, but these errors were encountered:
I have a
.swift-format
file at the root of my repo, but some third-party code in a sub-directory. I'd like to be able to disable formatting for the subdirectory.There are a couple of ways that this could be accomplished
.swift-format
with a pattern or patterns for paths to be excluded from formatting.no-swift-format
and disabling formatting anywhere below that file in the treeThe former case is useful, but would not be sufficient in the situation where you've a submodule with some third-party code, and that submodule has its own
.swift-format
file. In that situation the module's file would take precedence as it is closest, but you'd want to be able to override it locally without having to make changes to it.Detecting a
.no-swift-format
file at the same level would be efficient in this situation, and the file could be added to.gitignore
for the module, so that creating it locally would not cause upstream problems.The text was updated successfully, but these errors were encountered: