Git ve sabit bağlantılar

98

Git'in deponun dışına işaret eden sembolik bağları tanımadığını düşünürsek, sabit bağları kullanırken herhangi bir sorun var mı?

Git onları kırabilir mi? Lütfen beni detaylı bilgiye yönlendirir misiniz?

linux  git  hyperlink  hardlink 
— Alfredo Palhares
kaynak
2
Ne yapmaya çalışıyorsun ve neden? Sabit bağlantı normal bir dosyadan farklı değildir. Başka bir depodan yeni bir sürüm alacak olsaydınız, sahip olduğunuzun üzerine yazardı - deponun dışındaki bir şeye bağlanmanın amacı nedir?
— Carl Norum
2
Git, deponun dışındaki bir yola işaret eden sembolik bağları tanıyacaktır.
— mipadi
Mipadi yok, tek yol depodaki dosyaları ve sembolik bağlantıları "gerçek" konumlarında
— sallamak

Yanıtlar:

89

Git'teki dizinleri temsil eden 'ağaç' nesnesi, dosya adını ve (alt kümesini) izinleri depolar. İnode numarasını (veya başka tür bir dosya kimliğini) saklamaz. Bu nedenle sabit bağlantılar GIT'de temsil edilemez , en azından değil gibi üçüncü parti araçlar olmadan, metastore veya git-cache-meta (ve eminim o bile bu araçlarla mümkün olup olmadığını değilim).

Git, güncellenmesi gerekmeyen dosyalara dokunmamaya çalışır, ancak git'in sabit bağlantıları korumaya çalışmadığını, böylece git tarafından koparılabileceklerini hesaba katmalısınız.

Hakkında dışında deposunu işaret sembolik linkleri : git onlarla hiçbir sorun vardır ve sembolik bağlantıların içeriğini korumak gerekir ... ama bu tür bağlantıların yarar bu sembolik bağ kırık olup olmayacağı gibi bana şüpheli ya da değil dosya sistemi düzeni bağlıdır dışında git depo ve git'in kontrolü altında değil.

— Jakub Narębski
kaynak
4
Depo dışındaki yollara sembolik bağlantılar yararlı olabilir. Bunları web uygulamalarında depo tarafından izlenmeyen veritabanına veya medya dosyalarına işaret etmek için kullandım. Bu şekilde, web uygulamasının yapılandırma dosyası statik bir yola işaret edebilir, ancak bu yolun gerçek konumu yerel geliştirme ve sunucu ortamları arasında değişebilir.
— mipadi
@mipadi: BTW. Modern gitweb, depo dışında normalleştirmeden sonra önde gelen sembolik bağları görüntülemek için özel bir duruma sahiptir.
— Jakub Narębski
6
Evet, repo dışındaki sembolik bağlantılar iyi. Bunları sürümlendirilmiş ihtiyacım olmayan (veya istemediğim) büyük bir veri dizinine işaret etmek için kullandım. Genelde göreli bağlantılar kullanırım. Bu durumda, depo ve veri dizininin bir üst dizinde yan yana oturması gerekebilir. ../Foo'ya sembolik bağlantılarla harika numaralar yapabilirsiniz.
— Adrian Ratnapala
Maalesef metastore için Git deposu (git: //git.hardeman.nu/metastore.git) artık mevcut değil.
— Derek Mahar
1
github.com/danny0838/git-store-meta , git-cache-meta için bir alternatiftir .
— Derek Mahar
22

Hook'ları kullanarak git pull, komut dosyası olay işleyicisini .git/hooks/post-mergedosyaya yazarak olayı yakalayabileceğinizi (çekecek bir şey olduğunda ...) yakalayabileceğinizi öğrendim .

İlk önce chmod +xbuna ihtiyacınız var.

Ardından, lnher çekişte sert bağlantıları yeniden oluşturmak için komutları içine yerleştirin. Düzgün ha!

Çalışıyor, sadece projem için buna ihtiyacım vardı ve ls -idosyaların daha sonra otomatik olarak bağlandığını gösteriyor pull.

Örneğim .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

ÖNEMLİ: Gördüğünüz gibi, deponuzdaki herhangi bir dosyanın yolu ile başlamalı $GIT_DIR, ardından dosyaya kısmi göreceli yolu eklemelisiniz.

Ayrıca önemli: -fhedef dosyayı yeniden oluşturduğunuz için gereklidir.

DÜZENLE

Modern git istemcisi, uzak bir konuma itip klonlarken bile, deponun içindeki sembolik bağlantıları ve sabit bağlantıları doğal olarak destekliyor gibi görünüyor. Gerçi bir daha git deposu dışında bağlantı kurma ihtiyacım olmadı ...

$ mkdir tmp
$ cd tmp
$ git --version
git version 2.24.3 (Apple Git-128)
$ git init .
Initialized empty Git repository in /Users/teixeira/tmp/.git/
$ mkdir x
$ cd x
$ echo 123 > original
$ cat original
123
$ cd ..
$ ln -s x/original symlink
$ cat symlink
123
$ ln x/original hardlink
$ cat hardlink
123
$ git add .
$ git commit -m 'Symlink and hardlink commit'
[master (root-commit) 8df3134] Symlink and hardlink commit
 3 files changed, 3 insertions(+)
 create mode 100644 hardlink
 create mode 120000 symlink
 create mode 100644 x/original

Yerel git deposundan klonlama

$ cd
$ git clone tmp/ teste_tmp
Cloning into 'teste_tmp'...
done.
$ cd teste_tmp/
$ ls
hardlink  symlink  x
$ cat symlink
123
$ cat hardlink
123

Uzak depodan klonlama

$ cd ~/tmp
$ git remote add origin https://github.com/myUser/myRepo.git
$ git push origin master
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (5/5), 361 bytes | 361.00 KiB/s, done.
Total 5 (delta 0), reused 0 (delta 0)
To https://github.com/myUser/myRepo.git
 + 964dfce...8df3134 master -> master
$ cd ../
$ git clone https://github.com/myUser/myRepo.git
Cloning into 'myRepo'...
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 5 (delta 0), reused 5 (delta 0), pack-reused 0
Unpacking objects: 100% (5/5), done.
$ cd myRepo/
$ cat symlink
123
$ cat hardlink
123

https://github.com/mokacoding/symlinks ayrıca önemli bir şeye işaret ediyor: sembolik bağlar göreceli olarak tanımlanmalıdır.

— Niloct
kaynak
11
Dolayısıyla, deponuza her sabit bağlantı eklediğinizde, birleştirme sonrası kanca komut dosyanıza manuel olarak da bir satır eklemeniz gerekiyor gibi görünüyor. Pre-commit kancanız bunu tamamen otomatik hale getirseydi - commitinizdeki zor (ve sembolik) bağlantıları tespit edip post-birleştirme dosyanıza uygun satırları yazarsanız iyi olurdu. Git inode bilgisini depoda saklamak zorunda kalmazdı, onun bitlerini kancalarda saklardı! Ancak, bağlantılı dosya başka bir git deposunda izlenirse ... bir yerde dosyada yapılan bir düzenleme diğer depoya sorunsuz bir şekilde yayılır mı? Dairesel bir itme / çekme döngüsüyle sürekli birleştirmeler?
— ocaklar
Akıllıca bir yaklaşım, ancak Git'in sabit bağlantıları izlememesi talihsiz bir durumdur, hatta potansiyel olarak bunları sabit bağlantıları desteklemeyen dosya sistemlerinde kopyalar olarak temsil eder.
— Derek Mahar
1
@hobs cevaplamak için 7 yıl ayırdığım için üzgünüm :) Haklısın. Depo dışındaki bir dosya 2 farklı depo ile bağlanmışsa, bir depodaki bir bağlantıyı değiştirmenin diğerinde görülmeyeceğini düşünüyorum.
— Niloct
8

Bu msysgit sayısından

Birleşme noktaları sembolik bağlantılar değildir; bu nedenle sembolik bağlantılar msysGit'te desteklenmez.

Ayrıca, sabit bağlantılar asla Git tarafından izlenmedi .

Sorun Windows yönelimliydi (çünkü mesysgit hakkında) ve sembolik bağın olası desteği hakkında tartışma.
Ancak sabit bağlantı hakkındaki yorum genel olarak Git ile ilgilidir.

— VonC
kaynak
2

Google 'git sabit bağlantıları koruyor' ve bu, git'in AFAIK sabit bağlantı yapısını, belki de tasarım gereği nasıl koruyacağını bilmediğini gösteriyor.

Benim web projelerim aşağıdaki gibi sabit bağlantılar kullanıyor:

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)

me@server:www/products$ ls -l index.php
-rwxr-xr-x 3 me me 1958 Aug 22 22:10 index.php*

İndex.php'de değişiklik yapmak istersem, onu bir yerde değiştiririm ve sabit bağlantılar (ürün detay sayfaları) değişiklikleri gösterir - sadece git, klonlama ve diğer bilgisayarları çekme sırasında bu ilişkiyi korumaz.

me@server:www$ git pull

başka bir makinede her sabit bağlantı için yeni bir index.php yaratacaktır.

— xce_git
kaynak
7
Web uygulamanızda bir çeşit yönlendirme uygulamalısınız. Sert bağlantı tuhaftır.
— Nowaker
5
Evet, en azından sembolik bağlantılar kullanın. :)
— Andres Riofrio
2
Aslında istediğim bu, git'in sabit bağlantıları korumasını istemiyorum. Tonlarca çalışma alanı dizinine sahip bir Jenkins dizinim var ve çok şubeli ardışık düzenler nedeniyle çok sayıda yineleme var. Bunu geceleri iş var Yani ishal olduğu hardlink --ignore-timeüzerinde /var/lib/jenkinsbazı disk alanını geri kazanmak. Gün boyunca bazı dosyaların sabit bağlantısı kaldırıldıktan sonra git pullveya mvn compilebu sorun değil, bunun olmasını bekliyorum. Git sabit bağlantıları korumak için olsaydı, disk alanı geri dönüştürme stratejim işe yaramazdı.
— Amedee Van Gasse
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.