2
etckeeperのメタデータエンジンを/ etc以外のファイルシステムのgitコントロールに再利用/拡張する方法、または上記の機能を使用してgitをネイティブに拡張する方法
概要+質問 etckeeperのような、/ etc以外のgit制御ディレクトリのファイルシステムメタデータ制御が必要です。とりわけ、ホームおよびweb-appディレクトリは、メタデータ（ファイルの所有権、ACL、アクセス権）に古典的に敏感です。これは、特にFabricのようなツールとともに、自動サーバー展開に gitを使用するのに非常に有用/重要です。etcdirでetckeeperのような機能を、etckeeper自体または他の何かで再利用したいと思います。 誰でも次のいずれかまたは両方を提供するためのヒント/トリック/作業ソリューションを提案できますか？ etckeeperエンジンを（etckeeperのgit固有の機能のみに注意して）/ etc以外のgitが制御するディレクトリに適用します。（少なくともDebian / Ubuntu Linuxを想定できます。可能であればMacOSX / homebrewのサポートを希望します。） メタデータのサポートでgitを拡張し（git-cache-metaのような単純化しすぎたものを超えて）、etckeeperのような機能をサポートしますか？ 詳細、背景 filesystem-metadata-control機能を使用してgitを拡張することに関心が高まっています。etckeeperのメタデータ「エンジン」は、私の経験では非常に強力で信頼性があり、etckeeperは他の人にも人気があるようです。 少なくとも一部は、メタストアの非テキストベース/マージ非友好的な課題のために、メタストアは少なくなっています。さらに、etckeeperはメタストアベースのコアで開始したように見えますが、その後独自の（投機的？）に切り替えました。 明らかに、これにはOS /ファイルシステム固有の依存関係があります。（たとえば、Windowsで自動デプロイを試行しない。）オプションを提案するgitの拡張（「ネイティブ拡張」の場合）、クロスプラットフォームの破損の結果を理解してユーザーがオンデマンドで有効にし、ネイティブの動作がgitの「デフォルト」のクロスプラットフォームの使いやすさを壊さないようにします。さらに、贅沢なunix / darwin / etcメタデータ（ACLなど）を保存する必要はありません。基本的なユーザー/グループ/その他のパーマとユーザー/グループの所有権は問題ありません。（これらは私の「セキュリティ/脆弱性制御/ポリシー」で現在物事を壊している唯一のものです。）私が前もってターゲットにしている特定のOS：Debian、Ubuntu、MacOS 10.6+。後で：Redhat（CentOS、Fedora、RHEL）、SUSE、その他のLinux、および* BSD（FreeBSD、NetBSD、OpenBSD）。Windows / VMS（VMSはposixに対応している可能性はありますが）やその他の非UNIX系OSの予見可能な時点でのニーズ/アプリケーションを見ないでください。 参照：既存のgitの背景、私が投稿したこのstackoverflowの質問でのファイルメタデータ/ファイルタイプの追跡機能。 新しいプロジェクトの要件を作成しますか？ さらに、誰かがそのような機能の要件を作成することに関心がある場合、特に上記の新しい/未完了のプロジェクトに役立つことを確信できます。