Comments (11)
Please consider that devs may be lazy people and do that anyway to save time
Nowadays, It could be considered that lazy people have no rights to their privacy. Could be seen with the example of the Accept All
/Let me choose my...
tracking cookies on the European internet. π
Basically any dot file is dubious?
That was my initial idea with the recent exclusion logic rewrite.
Initially I used a .gitignore
-like file to exclude .dotfiles in the root directory.
But later when I rewrote it to a more "Pythonic" regex expression list, a discussion has begun on the validity of excluding every .dotfile. The results were that, in some cases those files could be necessary to properly debug the project, and also they are sort of proof that people didn't go the extra step to reproduce their issue from scratch, which in many cases could lead to a discovery in user error, basically removing the need to send us the file altogether.
You can read the whole PR here: #6874
Your concerns have been heard and a proper warning will decrease the chance of people sending their private/sensitive data willy-nilly.
from mkdocs-material.
Addressed in f724bb9
from mkdocs-material.
Thanks for reporting. Note that this runs counter to the idea of a minimal reproduction β you should not pack up your project, but create a new one which only includes the parts that show an issue. Other than that, @kamilkrzyskow, should we add .git
to the list of exclusion patterns?
from mkdocs-material.
Sure, I believe a workflow where people prefer to delete stuff from their project on a branch to later simply git restore
if a file needs restoration is worth supporting.
I'm a bit ignorant about what security sensitive info can be stored in the .git cache, perhaps names of branches so more of a privacy matter. Private keys should not be stored there or should they π€
The exclusion pattern should likely also include inner subprojects as they could also have .git directories.
The patterns always are resolved from the beginning so /[^/]*\.git/
should do the trick.
from mkdocs-material.
I'm a bit ignorant about what security sensitive info can be stored in the .git cache, perhaps names of branches so more of a privacy matter. Private keys should not be stored there or should they π€
I'm also not entirely sure if we want the behavior that is asked for. We have some plugins we integrate with that demand a .git
repository for a working minimal reproduction, specifically:
- git-revision-date-localized
- git-authors
- git-committers
It is impossible for us to know which plugin needs the git history without creating yet another inclusion list, which is impractical. Minimal reproductions with those plugin would cease to work.
The exclusion pattern should likely also include inner subprojects as they could also have .git directories.
Now that I would've forgotten π« Great thinking.
Another idea: What if we just print a warning that a git repository was included? I think this should be sufficient for the author to know that it's there and decide whether it's necessary or not.
from mkdocs-material.
I've relabelled this issue from "bug" to "change request". It is sensical for us to include the repository for the reasons stated, but I understand that this is not what everybody might want.
from mkdocs-material.
Maybe this is a stretch, but let's check the names of plugins if they start with git-
as this is a pattern for this kind of modules.
If there are no git plugins found exclude the directory by adding the pattern dynamically.
The idea with the warning is also good as we want to make people aware they are about to post their private repository data.
This could be even an explicit input prompt to confirm saving the zip, and the user is aware what they're doing. Best to protect the project from angry developers claiming purposeful negligence with the info plugin.
from mkdocs-material.
Hmm, I not really for using heuristics that are based on mere conventions. I'd say we go with the warning, as the author might also not want to include the git repository, albeit his reproduction contains one of the git plugins, e.g. when another bug is reported. Since the author is explicitly invoking the mkdocs build
command and looks at the output the plugin produces, so the warning can be guaranteed to be seen.
from mkdocs-material.
you should not pack up your project, but create a new one which only includes the parts that show an issue.
Sureβ¦ Please consider that devs may be lazy people and do that anyway to save time π
from mkdocs-material.
The exclusion pattern should likely also include inner subprojects as they could also have .git directories. The patterns always are resolved from the beginning so
/[^/]*\.git/
should do the trick.
Maybe consider other stuff such as .gitmodules
, .github/
, .svn/
β¦ Basically any dot file is dubious?
from mkdocs-material.
Released as part of 9.5.21.
from mkdocs-material.
Related Issues (20)
- Add PlantUML Markdown extension schema HOT 1
- Version switcher lately never succeeds at staying on the same page HOT 15
- FR: Support Variable from Pyproject.toml HOT 1
- "Copy" in code blocks inject double newlines HOT 8
- Custom Icons: size and color info missing in documtation HOT 1
- multi blog instances share the same `post_date_format` date filter HOT 8
- Instant navigation: toc item requires two clicks after navigating away and returning HOT 5
- Default value for search-plugin separator has a typo HOT 1
- Version selector is not displayed correctly after enabling showing version alias HOT 4
- Mermaid Viewer Control box? How can we use it? HOT 5
- Insiders tag plugin conflicts with markdown_extensions.toc HOT 5
- Section display text alias overridden with same .md files HOT 2
- Add tab index to `.md-search__scrollwrap` in the `search` plugin HOT 10
- [change(feature) request] Page Subtitle for Blog Posts HOT 3
- Annotation doesn't work inside markdown tables HOT 2
- Running "mkdocs serve" through Docker results in "Connection reset by peer" HOT 4
- Comment: The comment page must be refreshed to appear. HOT 4
- included in the 'nav' configuration, which is not found in the documentation files. HOT 1
- Blog issue - TypeError: unsupported operand type(s) for |: 'ABCMeta' and 'NoneType' HOT 1
- Cannot use numbers as titles HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mkdocs-material.