2010-07-27 23 views
7

Tôi cần một cái gì đó giống như mô-đun con, nhưng tồn tại bên ngoài kho lưu trữ chính dưới dạng phụ thuộc.Làm cách nào để thêm kho lưu trữ git làm phụ thuộc chia sẻ của một kho lưu trữ git khác?

Dưới đây là các vấn đề:

Tôi đang cố gắng sử dụng Git (theo một cách vụng về REALLY) để quản lý các file thiết kế cho một công cụ CAD (Cadsoft Eagle), và tôi có một thời gian khó khăn để tìm nếu có một cách để sử dụng các mô đun con git để quản lý sự phụ thuộc của từng dự án khi thư viện được chia sẻ của công cụ CAD.

Tôi đang sử dụng một cấu trúc thư mục như thế này:

~/eagle/ <-- Main library used by multiple projects 
    .git/  
    <library files> 

~/projects/ <-- Projects folder 
    Proj0/ 
     .git/ 
     <design files> 
    Proj1/ 
     .git/ 
     <design files> 

Trong trường hợp này, nó không có ý nghĩa để thêm kho eagle.git như một submodule git cho từng dự án.

Tuy nhiên, tôi vẫn cần một cách để chụp nhanh trạng thái hiện tại của kho lưu trữ "eagle.git" để thư viện được cập nhật trong tương lai, nó có thể được cuộn lại để truy cập vào phiên bản cụ thể của các tệp thư viện đã được sử dụng khi Proj [x] được cam kết.

Lý tưởng nhất, tôi muốn một cái gì đó như sau:

~/eagle/ <-- Main library used by multiple projects 
    .git/  
    <library files> 

~/projects/ <-- Projects folder 
    Proj0/ 
     .git/ 
     <design files> 
     **eagle** <-- something that acts like a submodule 
         but which actually points to ~/eagle/ 
    Proj1/ 
     .git/ 
     <design files> 
     **eagle** <-- something that acts like a submodule 
         but which actually points to ~/eagle/ 

Tôi muốn để có thể:

cd ~/projects/Proj0 
git submodule update 

và có ~/đại bàng/thư mục tự động quay trở lại để bản sửa đổi đã được kiểm tra thành Proj0.

Bất kỳ ai biết gì về Git có thể cho phép loại hành vi này không?

+0

Bạn có thể làm rõ lý do tại sao mô-đun con sẽ không hoạt động cho bạn ở đây? Nghe có vẻ như tôi như các mô-đun con chính là những gì bạn cần. –

+0

Đối với công cụ CAD (Eagle) để "xem" một thư viện, nó phải được thêm vào các thiết lập đường dẫn của Eagle. Nếu tôi thêm repo thư viện "eagle" làm submodule cho mỗi dự án, tôi sẽ phải chắp thêm thủ công đường dẫn thư viện con của mỗi dự án, nó sẽ gây ra các bản sao của thư viện "eagle" để hiển thị trong Eagle's quản lý thư viện. Tìm ra những gì và quản lý những bản sao riêng biệt trong công cụ CAD sẽ là một cơn ác mộng. Ngoài ra, thư viện có thể là đơn đặt hàng có độ lớn lớn hơn các tệp dự án, do đó, có vẻ như thật lãng phí khi có [x] bản sao của nó nằm xung quanh trên đĩa. – cdwilson

+0

Một cách hữu ích để nghĩ về điều này là thông qua sự tương tự. Cho phép nói Eagle CAD công cụ là một nhà máy có thể làm cho một widget tại một thời điểm. Cho phép nói rằng mỗi dự án [x] .git repo được đại diện bởi một kế hoạch chi tiết sản xuất [x] cho một số widget [x] nhà máy sản xuất. Các repo eagle.git được đại diện bởi các thiết lập nhà máy (các máy móc, công nhân, nguyên liệu) cần thiết để làm cho rằng phụ tùng [x]. – cdwilson

Trả lời

4

Đối với mỗi dự án, thêm .git/móc/pre-cam kết (và chắc chắn rằng nó thực thi):

#!/bin/sh 
git --git-dir=~/eagle/.git log -1 --pretty=format:%H >.eagle_rev 
git add .eagle_rev 

Sau đó, đối với mỗi dự án:

git config alias.update-eagle '!git --git-dir=~/eagle/.git --work-tree=~/eagle checkout -q $(<.eagle_rev)' 

Khi bạn thực hiện một cam kết , nó sẽ ghi lại HEAD hiện tại của ~/eagle, và git update-eagle sẽ kiểm tra commit đó trong ~/eagle. (Sau đó, chỉ cần chắc chắn rằng bạn git checkout <branch> trong ~/eagle trước khi bạn thực hiện bất kỳ thay đổi nào.)

+0

mkarasek, bạn là người mới mẻ! Tôi đã không có manh mối về móc cho đến bây giờ ... Tuy nhiên, vì lý do nào đó, bằng cách sử dụng "~" trong đường dẫn --git-dir trả về lỗi "gây tử vong: Không phải là một kho git: '~/eagle/.git'". Tuy nhiên, nếu tôi thay thế "~" bằng "HOME HOME" (tức là '--git-dir = $ HOME/eagle/.git') thì nó hoạt động tốt. Bất kỳ ý tưởng tại sao "~" không hoạt động với --git-dir và --work-tree? – cdwilson

+0

Bạn nhận được lỗi đó với móc cam kết? Có thể là của bạn/bin/sh là có vấn đề với nó; thay thế dòng đầu tiên bằng #!/bin/bash và xem điều đó có khắc phục được sự cố hay không. (Nếu, mặt khác, bạn đang nhận được lỗi đó với bí danh, sau đó tôi không có ý tưởng.) – mkarasek

0

Nếu eagle không có vị trí của nó trong vòng một ProjX,
nhưng mỗi ProjX có thể sử dụng một phiên bản cụ thể của eagle,
thì:

Đối với mỗi ProjX, bạn cần phải:

  • MainProjX Git repo, trong đó bạn sẽ tìm thấy:
    • một ProjX
    • một phiên bản của eagle (tại cùng một mức hơn ProjX)

Mục tiêu của từng dự án MainProjX cha mẹ là giữ cùng các phiên bản của ProjXeagle , đó là ghi lại các phụ thuộc phù hợp.

~/projects/ <-- Projects folder 
    MainProj0 
     Proj0/ 
      .git/ 
      <design files> 
     eagle/ 
      .git/ 
      <library files> 

    MainProj1 
     Proj1/ 
      .git/ 
      <design files> 
     eagle/ 
      .git/ 
      <library files> 

Bây giờ, vâng, đó là rất nhiều 'eagle' trùng lặp, nhưng điều đó là cần thiết nếu mỗi ProjX là có thể sử dụng eagle phiên bản riêng của mình.

+0

VonC, cảm ơn bạn đã trả lời nhanh. Vâng, đó là điều duy nhất tôi có thể đưa ra ... Vấn đề là repo 'đại bàng' có thể rất lớn (toàn bộ thư viện cad) trong khi Proj [x] repos rất nhỏ. Như bạn đã nói, tôi sẽ phải giữ khoảng tấn bản sao của các 'đại bàng' repos, và thậm chí tệ hơn, tôi sẽ phải tự thay đổi đường dẫn thư viện của công cụ CAD để cá nhân Proj [x]/eagle/dir cho công cụ để thậm chí nhìn thấy chúng, mà làm cho phương pháp này thực tế không sử dụng được. – cdwilson

+1

@lotharsmash: không phải là đường dẫn tương đối "' ../ eagle' "là đủ cho mỗi đường dẫn thư viện không? (Kể từ khi 'đại bàng' sẽ ở cùng cấp độ với' ProjX') – VonC