Propose not skipping hidden folders/files #221
Comments
|
Ref #211 |
|
Let me see if I understand the use case. There are source files (assets of templates) that are hidden or in hidden folders because in the output they are expected to be there and hidden? You gave the example of As you pointed out, the challenge with this is there are a lot of dot files that someone would expect to not be copied over. So we have two choices
I feel the latter would follow the principle of least surprise to users and is the direction I'm leaning. Also, there is precedence in at least Jekyll. I've actually started work on this in my dev branch but have been stalled on it because I've been spending time on polishing Liquid first. |
|
I agree with you that the
is the preferred solution to this. But yes, you are right, there is a need to have certain hidden files and folders in your site structure for various reasons, I am happy to carry on with this from your dev branch if you like. Currently I am looking at addressing #208 as it's something I also want |
|
My dev branch is a lot bigger change than just this. If you'd like this sooner than later, feel free to add this feature and send a PR. I was actually thinking of suggesting #208 to you. I have a couple of ideas for it I'll post over there. |
|
No problem. I'll make a start soon. I've started in the new post issue, but not with subcommand plugins. I'll probably put that down the list and push this up then. |
epage
added a commit
to epage/cobalt.rs
that referenced
this issue
May 22, 2017
The `ignore` field in `.cobalt.yml` is changing from a list of glob patterns to a list `gitignore` patterns, allowing whitelisting and more advanced whitelisting/blacklisting with well defined semantics. Previuously, Cobalt processed all files except `.dot` and `_hidden`, *dest* files/directories. Considerations when designing this: - User workflow: users need `.dot` asset files, like `.htaccess`, copied over. - Implementation: Finding files or pages and posts is coupled together which will be a problem as we refactor them into more general collections or sections. - Performance: Eventually we'll want to implement incremental rebuild (see issue cobalt-org#81) and to do so we'll need to know what collection a file notification is relevant to. `gitignore` patterns were selected for the first item to ensure we had well defined semantics for how blacklist and whitelist features would interact. The last two are the motivation for factoring out file detection. Debugging impact: Ideally we'd provide a way for user's to find out why a file is whitelisted or blacklisted but that is being left for a future change. Fixes cobalt-org#221 by allowing the user to whitelist `.dot` and `_hidden` files. See the added unit tests for examples. BREAKING CHANGE: The format of `.cobalt.yml`'s `ignore` field has changed from a glob pattern to use gitignore patterns.
epage
added a commit
to epage/cobalt.rs
that referenced
this issue
May 22, 2017
The `ignore` field in `.cobalt.yml` is changing from a list of glob patterns to a list `gitignore` patterns, allowing whitelisting and more advanced whitelisting/blacklisting with well defined semantics. Previuously, Cobalt processed all files except `.dot` and `_hidden`, *dest* files/directories. Considerations when designing this: - User workflow: users need `.dot` asset files, like `.htaccess`, copied over. - Implementation: Finding files or pages and posts is coupled together which will be a problem as we refactor them into more general collections or sections. - Performance: Eventually we'll want to implement incremental rebuild (see issue cobalt-org#81) and to do so we'll need to know what collection a file notification is relevant to. `gitignore` patterns were selected for the first item to ensure we had well defined semantics for how blacklist and whitelist features would interact, directory vs file patterns, etc. The last two are the motivation for factoring out file detection. Debugging impact: Ideally we'd provide a way for user's to find out why a file is whitelisted or blacklisted but that is being left for a future change. Fixes cobalt-org#221 by allowing the user to whitelist `.dot` and `_hidden` files. See the added unit tests for examples. BREAKING CHANGE: The format of `.cobalt.yml`'s `ignore` field has changed from a glob pattern to use gitignore patterns.
epage
added a commit
to epage/cobalt.rs
that referenced
this issue
May 23, 2017
The `ignore` field in `.cobalt.yml` is changing from a list of glob patterns to a list `gitignore` patterns, allowing whitelisting and more advanced whitelisting/blacklisting with well defined semantics. Previuously, Cobalt processed all files except `.dot` and `_hidden`, *dest* files/directories. Considerations when designing this: - User workflow: users need `.dot` asset files, like `.htaccess`, copied over. - Implementation: Finding files or pages and posts is coupled together which will be a problem as we refactor them into more general collections or sections. - Performance: Eventually we'll want to implement incremental rebuild (see issue cobalt-org#81) and to do so we'll need to know what collection a file notification is relevant to. `gitignore` patterns were selected for the first item to ensure we had well defined semantics for how blacklist and whitelist features would interact, directory vs file patterns, etc. The last two are the motivation for factoring out file detection. Debugging impact: Ideally we'd provide a way for user's to find out why a file is whitelisted or blacklisted but that is being left for a future change. Fixes cobalt-org#221 by allowing the user to whitelist `.dot` and `_hidden` files. See the added unit tests for examples. BREAKING CHANGE: The format of `.cobalt.yml`'s `ignore` field has changed from a glob pattern to use gitignore patterns.
epage
added a commit
to epage/cobalt.rs
that referenced
this issue
May 23, 2017
The `ignore` field in `.cobalt.yml` is changing from a list of glob patterns to a list `gitignore` patterns, allowing whitelisting and more advanced whitelisting/blacklisting with well defined semantics. Previuously, Cobalt processed all files except `.dot` and `_hidden`, *dest* files/directories. Considerations when designing this: - User workflow: users need `.dot` asset files, like `.htaccess`, copied over. - Implementation: Finding files or pages and posts is coupled together which will be a problem as we refactor them into more general collections or sections. - Performance: Eventually we'll want to implement incremental rebuild (see issue cobalt-org#81) and to do so we'll need to know what collection a file notification is relevant to. `gitignore` patterns were selected for the first item to ensure we had well defined semantics for how blacklist and whitelist features would interact, directory vs file patterns, etc. The last two are the motivation for factoring out file detection. Debugging impact: Ideally we'd provide a way for user's to find out why a file is whitelisted or blacklisted but that is being left for a future change. Fixes cobalt-org#221 by allowing the user to whitelist `.dot` and `_hidden` files. See the added unit tests for examples. BREAKING CHANGE: The format of `.cobalt.yml`'s `ignore` field has changed from a glob pattern to use gitignore patterns.
epage
added a commit
to epage/cobalt.rs
that referenced
this issue
May 23, 2017
The `ignore` field in `.cobalt.yml` is changing from a list of glob patterns to a list `gitignore` patterns, allowing whitelisting and more advanced whitelisting/blacklisting with well defined semantics. Previuously, Cobalt processed all files except `.dot` and `_hidden`, *dest* files/directories. Considerations when designing this: - User workflow: users need `.dot` asset files, like `.htaccess`, copied over. - Implementation: Finding files or pages and posts is coupled together which will be a problem as we refactor them into more general collections or sections. - Performance: Eventually we'll want to implement incremental rebuild (see issue cobalt-org#81) and to do so we'll need to know what collection a file notification is relevant to. `gitignore` patterns were selected for the first item to ensure we had well defined semantics for how blacklist and whitelist features would interact, directory vs file patterns, etc. The last two are the motivation for factoring out file detection. Debugging impact: Ideally we'd provide a way for user's to find out why a file is whitelisted or blacklisted but that is being left for a future change. Fixes cobalt-org#221 by allowing the user to whitelist `.dot` and `_hidden` files. See the added unit tests for examples. BREAKING CHANGE: The format of `.cobalt.yml`'s `ignore` field has changed from a glob pattern to use gitignore patterns.
epage
added a commit
to epage/cobalt.rs
that referenced
this issue
May 24, 2017
The `ignore` field in `.cobalt.yml` is changing from a list of glob patterns to a list `gitignore` patterns, allowing whitelisting and more advanced whitelisting/blacklisting with well defined semantics. Previuously, Cobalt processed all files except `.dot` and `_hidden`, *dest* files/directories. Considerations when designing this: - User workflow: users need `.dot` asset files, like `.htaccess`, copied over. - Implementation: Finding files for pages and posts is coupled together which will be a problem as we refactor them into more general collections or sections. - Performance: Eventually we'll want to implement incremental rebuild (see issue cobalt-org#81) and to do so we'll need to know what collection a file notification is relevant to. `gitignore` patterns were selected for the first item to ensure we had well defined semantics for how blacklist and whitelist features would interact, directory vs file patterns, etc. The last two are the motivation for factoring out file detection. A couple downsides, for now - `cobalt watch` will now rebuild when hidden files are touched. This is unfortunate but seems like an acceptable short term sacrifice until we have a better to expose what files cobal reads. - Handling of overlapping source/dest is a bit ugly. In the future, we should just make these cases error - Handling of hidden post folders is ugly. In the future, we should generalize the concept of pages and posts into collections/sections at which point we'll walk each collection type independently. This will make the non-hidden posts folders the ugly case. We should consider requiring them to be hidden. - There is a known bug where we enable all hidden folders that match the posts folders name rather than only some. Fixes cobalt-org#221 by allowing the user to whitelist `.dot` and `_hidden` files. See the added unit tests for examples. BREAKING CHANGE: The format of `.cobalt.yml`'s `ignore` field has changed from a list of glob patterns to gitignore patterns.
epage
added a commit
to epage/cobalt.rs
that referenced
this issue
May 24, 2017
The `ignore` field in `.cobalt.yml` is changing from a list of glob patterns to a list `gitignore` patterns, allowing whitelisting and more advanced whitelisting/blacklisting with well defined semantics. Previuously, Cobalt processed all files except `.dot` and `_hidden`, *dest* files/directories. Considerations when designing this: - User workflow: users need `.dot` asset files, like `.htaccess`, copied over. - Implementation: Finding files for pages and posts is coupled together which will be a problem as we refactor them into more general collections or sections. - Performance: Eventually we'll want to implement incremental rebuild (see issue cobalt-org#81) and to do so we'll need to know what collection a file notification is relevant to. `gitignore` patterns were selected for the first item to ensure we had well defined semantics for how blacklist and whitelist features would interact, directory vs file patterns, etc. The last two are the motivation for factoring out file detection. A couple downsides, for now - `cobalt watch` will now rebuild when hidden files are touched. This is unfortunate but seems like an acceptable short term sacrifice until we have a better to expose what files cobal reads. - Handling of overlapping source/dest is a bit ugly. In the future, we should just make these cases error - Handling of hidden post folders is ugly. In the future, we should generalize the concept of pages and posts into collections/sections at which point we'll walk each collection type independently. This will make the non-hidden posts folders the ugly case. We should consider requiring them to be hidden. - There is a known bug where we enable all hidden folders that match the posts folders name rather than only some. Fixes cobalt-org#221 by allowing the user to whitelist `.dot` and `_hidden` files. See the added unit tests for examples. BREAKING CHANGE: The format of `.cobalt.yml`'s `ignore` field has changed from a list of glob patterns to gitignore patterns.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The walkdir dir filter skips files prefixed with
_and.. However hidden folders are required for example to prove keybase identity and setup Let's Encrypt verifications in a.well-knownfolder.Would it make sense to not skip hidden files and folders?
Although wrangling files like
.cobalt.yml,.gitlab-ci.yml, etc would require them to be added to the ignore list in the config. This could be done by providing a default set of the most common config and directories.Alternatively add an option to force include certain folders and files, somewhat like Pelican does
The text was updated successfully, but these errors were encountered: