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
Thanks for developing this useful tool. I discovered DMeta while searching for a pre-commit hook that can automatically remove metadata from Excel files before committing them to Git. I couldn't find an existing pre-commit hook for this purpose.
It would be helpful if DMeta had a pre-commit hook. Would you consider implementing this by adding a .pre-commit-hooks.yaml file? Possible options include:
Adding it to the same repository (openscilab/dmeta)
Creating a separate repository (e.g., openscilab/pre-commit-hook-dmeta)
Hosting it in a third-party repository
For pre-commit users, option 1 seems to be the most straightforward choice. However, if you prefer not to add a tool-specific file to the repository or not to maintain a separate tool-specific repository, option 2 or 3 would be reasonable.
@tueda
Thank you for your insightful suggestion! I really appreciate you proposing the idea of adding a pre-commit hook to automatically remove metadata from Excel files before committing them to Git. It's a very useful feature. We're also planning to broaden the supported formats, so it can be extended beyond Microsoft Office files.
I'll certainly take this into consideration for one of the upcoming milestones of DMeta.
Thanks for developing this useful tool. I discovered DMeta while searching for a pre-commit hook that can automatically remove metadata from Excel files before committing them to Git. I couldn't find an existing pre-commit hook for this purpose.
It would be helpful if DMeta had a pre-commit hook. Would you consider implementing this by adding a
.pre-commit-hooks.yaml
file? Possible options include:openscilab/dmeta
)openscilab/pre-commit-hook-dmeta
)For pre-commit users, option 1 seems to be the most straightforward choice. However, if you prefer not to add a tool-specific file to the repository or not to maintain a separate tool-specific repository, option 2 or 3 would be reasonable.
See also:
The text was updated successfully, but these errors were encountered: