Xem xét Git không nhận ra các liên kết tượng trưng nằm ngoài kho lưu trữ, có vấn đề gì khi sử dụng liên kết cứng không?Git và các liên kết cứng
Git có thể phá vỡ chúng không? Bạn có thể vui lòng chỉ cho tôi thông tin chi tiết không?
Đối tượng 'cây', đại diện cho các thư mục trong Git, lưu trữ tên tệp và quyền (tập hợp con). Nó không lưu trữ số inode (hoặc loại tập tin id khác). Do đó, các liên kết cứngkhông thể được trình bày trong git, ít nhất là không có các công cụ của bên thứ ba như metastore hoặc git-cache-meta (và tôi không chắc chắn liệu có thể có ngay cả với các công cụ đó) hay không.
Git cố gắng không chạm vào các tệp mà nó không cần cập nhật, nhưng bạn phải tính đến việc git không cố giữ lại các liên kết cứng, vì vậy chúng có thể bị hỏng bởi git.
Về liên kết tượng trưng chỉ bên ngoài kho: git không có vấn đề với họ và nên duy trì nội dung của liên kết tượng trưng ... nhưng tiện ích của liên kết như vậy là không rõ ràng với tôi, như liệu những liên kết tượng trưng sẽ được chia hoặc không phụ thuộc vào bố cục hệ thống tệp bên ngoài kho lưu trữ git và không dưới sự kiểm soát của git.
Các liên kết tới đường dẫn bên ngoài repo có thể hữu ích. Tôi đã sử dụng chúng trong webapps để trỏ đến cơ sở dữ liệu hoặc các tập tin media không được theo dõi bởi repo. Bằng cách đó, tệp cấu hình của ứng dụng web có thể trỏ đến một đường dẫn tĩnh, nhưng vị trí thực tế của đường dẫn đó có thể khác nhau giữa môi trường phát triển và máy chủ cục bộ. – mipadi
@mipadi: BTW. Gitweb hiện đại có trường hợp đặc biệt để hiển thị các liên kết tượng trưng sau khi chuẩn hóa bên ngoài kho lưu trữ. –
Đúng, các liên kết bên ngoài repo là tốt. Tôi đã sử dụng chúng để trỏ đến một thư mục dữ liệu khổng lồ mà tôi không cần (hoặc muốn) được phiên bản. Nói chung tôi sử dụng các liên kết tương đối. Vì vậy, trong trường hợp có thể các repo và thư mục dữ liệu đã phải ngồi bên cạnh nhau trong một số thư mục cha mẹ. Bạn có thể thực hiện các thủ thuật tuyệt vời bằng một liên kết tượng trưng đến ../foo. –
Từ này msysgit issue
điểm Junction là liên kết không mang tính biểu tượng; do đó, các liên kết tượng trưng đơn giản là không được hỗ trợ trong msysGit.
Ngoài ra, liên kết cứng chưa bao giờ được theo dõi bởi Git.
Vấn đề là hướng Windows (vì nó là về msysgit) và tranh luận về khả năng hỗ trợ của liên kết tượng trưng.
Nhưng nhận xét về mối quan tâm liên kết cứng Git nói chung.
Google 'git giữ liên kết cứng' và nó cho thấy git không biết cách bảo toàn cấu trúc liên kết cứng AFAIK, có lẽ do thiết kế.
dự án Web của tôi sử dụng liên kết cứng như sau:
www/products/index.php
www/products/dell_latitude_id577/index.php #(hard linked to above)
www/products/dell_inspiron_id323/index.php #(hard linked again to above)
[email protected]:www/products$ ls -l index.php
-rwxr-xr-x 3 me me 1958 Aug 22 22:10 index.php*
Nếu tôi muốn thay đổi index.php tôi thay đổi nó ở một nơi và các liên kết cứng (trang chi tiết sản phẩm) trỏ đến những thay đổi - ngoại trừ git không bảo toàn mối quan hệ này trong quá trình nhân bản và kéo trên các máy tính khác.
[email protected]:www$ git pull
trên máy khác sẽ tạo index.php mới cho từng liên kết cứng.
Bạn nên triển khai một số loại định tuyến trong ứng dụng web của mình. Liên kết cứng là kỳ quái. – Nowaker
Vâng, ít nhất sử dụng các liên kết tượng trưng. :) –
Ok, bây giờ đây là một câu trả lời cuối = D
tôi phát hiện ra rằng, sử dụng lưỡi câu, bạn có thể nắm bắt những sự kiện git pull (khi có cái gì đó để kéo ...) viết kịch bản xử lý sự kiện để .git/hooks/post-merge tập tin.
Trước tiên, bạn phải chmod +x.
Sau đó, đặt các lệnh ln vào bên trong để tạo lại các liên kết cứng tại mỗi lần kéo. Neat huh!
Nó hoạt động, tôi chỉ cần cho dự án của tôi và ls -i cho thấy các tệp được tự động liên kết sau pull.
dụ của tôi về .git/hooks/post-merge:
#!/bin/sh
ln -f $GIT_DIR/../apresentacao/apresentacao.pdf $GIT_DIR/../capa/apresentacao.pdf
ln -f $GIT_DIR/../avaliacoesMono/avaliacao_monografias_2011_Nilo.pdf $GIT_DIR/../capa/avaliacoes.pdf
ln -f $GIT_DIR/../posters/poster_Nilo_sci.pdf $GIT_DIR/../capa/poster.pdf
ln -f $GIT_DIR/../monografia/monografia_Nilo.pdf $GIT_DIR/../capa/monografia_Nilo.pdf
QUAN TRỌNG: Như bạn thấy, con đường dẫn đến bất kỳ tập tin trong kho của bạn nên bắt đầu với $GIT_DIR, sau đó thêm đường dẫn tương đối một phần vào tập tin.
Cũng quan trọng: -f là cần thiết, vì bạn đang tạo lại tệp đích.
Vì vậy, có vẻ như mỗi khi bạn thêm một liên kết cứng vào repo của bạn, bạn cũng cần phải thêm một dòng vào kịch bản móc sau hợp nhất của bạn theo cách thủ công. Sẽ được tốt đẹp nếu móc trước khi cam kết của bạn thực hiện điều này hoàn toàn tự động - phát hiện các liên kết cứng (và tượng trưng) trong cam kết của bạn và viết các dòng thích hợp vào tệp sau hợp nhất của bạn. Git sẽ không phải lưu trữ thông tin inode trong repo, nó sẽ lưu trữ bit của nó trong móc! Nhưng những gì một mớ hỗn độn nếu các tập tin được liên kết đã được theo dõi trong một repo git ... sẽ sửa một tập tin ở một nơi tuyên truyền cho repo khác thuận lợi? Kết hợp vĩnh viễn với vòng lặp đẩy/kéo tròn? – hobs
Cách tiếp cận thông minh, nhưng thật không may là Git không theo dõi các liên kết cứng, thậm chí có khả năng biểu diễn chúng dưới dạng bản sao trên các hệ thống tệp không hỗ trợ liên kết cứng. –
Bạn đang cố gắng làm gì và tại sao? Liên kết cứng không khác với tệp bình thường. Nếu bạn đã từng kéo một phiên bản mới từ một kho lưu trữ khác, nó sẽ ghi đè lên phiên bản bạn đã có - điểm liên quan đến thứ gì đó bên ngoài repo là gì? –
Git sẽ nhận ra các liên kết tượng trưng trỏ đến đường dẫn bên ngoài kho lưu trữ. – mipadi
Không có mipadi, cách duy nhất là vẫy các tệp trong repo và các liên kết symjbolic trong vị trí "thực" của chúng –