そこにおいて：
異なるリポジトリ repoA、repoB、および repoC があり、それぞれが同じディレクトリ レイアウトの原則に従っており、これらは 3 番目の repoM の作業ディレクトリ (「マスター」プロジェクト) にマージされます。
repoM には非定型のセットアップがあります (--work-dir と --git-dir は別です)。repo[AC] はベアとしてクローンされ、 および として設定されcore.bare = falseますcore.worktree=<--work-dir-of-repoM>。
要求事項：
repo[AC] に由来する可能性のある、repoM の作業ディレクトリ内のすべてのファイルの履歴の概要を常に把握する必要があります。このアプローチでは、すべての情報が失われます。
別：
代わりに git-subtree を使用することを考えていました ( git version 1.7.11.2、したがって、既に組み込まれています)、 repo[AC] をそのままにして、
git pull -s subtree、またはgit subtree ...
サブツリーのプル戦略では、マージの競合で履歴が失われます (git blameそう言います)。
以前にサブツリーを使用したことはありませんが、私の理解では、ファイルをレポ [AC] からレポ M の作業ディレクトリにマージすることはできません。これらのファイルは、レポ [AC] のサブディレクトリに配置する必要があります。これは間違いなく私が必要とするものではありません。なんで？以下の理由で...
問題文：
さまざまな git リポジトリがあり、それぞれにさまざまなファイル セット (通常は構成ファイルといくつかのシェル スクリプト) が含まれています。これらすべてのリポジトリから$HOME(これは) ディレクトリにすべてを配置します。<--work-dir-of-repoM>各ファイルがどこから来たのかを常に確認し、編集、コミット、および変更をそれぞれの にプッシュできるはずですorigin。ご想像のとおり、 vundleのようなものですが、 vim bundlesだけでなく、あらゆるプログラムのあらゆる種類の構成に一般化されています。競合が発生した場合、同じファイルのどの 2 人の作成者が互いに連絡を取り合い、取引を成立させる必要があるかを追跡できるはずです (取引が必要な場合)。
これは、私がプロトタイプを機能させようとしているオープンソース プロジェクトのためのものです。同様の方法でこれを行う既存のプロジェクトについてのアイデアも高く評価されます。
注:「マスター ディレクトリ」は必ずしも である必要はありません$HOME。これで解決できる問題の種類に関するヒントとして使用しました。