Git dosya adlarını değil dosya içeriğini izler. Bu nedenle, içeriğini değiştirmeden bir dosyayı yeniden adlandırmak git'in algılaması kolaydır. (Git izlemez, ancak algılama gerçekleştirir ; git mvveya kullanarak git rmve git addetkin olarak aynıdır.)
Depoya bir dosya eklendiğinde, dosya adı ağaç nesnesindedir. Gerçek dosya içerikleri , depoya ikili büyük nesne ( blob ) olarak eklenir . Git, aynı içeriği içeren ek dosyalar için başka bir blob eklemeyecektir. Aslında, içerik dosya sisteminde saklandığı için, hash'in ilk iki karakteri dizin adı ve geri kalanı içindeki dosyanın adı olduğu için Git olamaz. Dolayısıyla, yeniden adları tespit etmek, karmaları karşılaştırmaktan geçer.
Yeniden adlandırılmış bir dosyadaki küçük değişiklikleri tespit etmek için Git, bunun bir yeniden adlandırma olup olmadığını görmek için belirli algoritmalar ve bir eşik sınırı kullanır. Örneğin, -Mbayrağına bir göz atın git diff. merge.renameLimit(Birleştirme sırasında yeniden adlandırma algılaması gerçekleştirirken dikkate alınacak dosya sayısı) gibi yapılandırma değerleri de vardır .
Git'in benzer dosyalara nasıl davrandığını anlamak için (yani, hangi dosya dönüşümlerinin yeniden ad olarak kabul edildiğini) anlamak için , yukarıda belirtildiği gibi yapılandırma seçeneklerini ve mevcut bayrakları inceleyin. Nasıl olduğunu bilmenize gerek yok. Git'in bu görevleri gerçekte nasıl gerçekleştirdiğini anlamak için, metindeki farklılıkları bulmaya yönelik algoritmalara bakın ve git kaynak kodunu okuyun.
Algoritmalar yalnızca fark, birleştirme ve günlük amaçları için uygulanır - git'in bunları saklama şeklini etkilemezler. Dosya içeriğindeki herhangi bir küçük değişiklik, onun için yeni bir nesnenin eklendiği anlamına gelir. Bu seviyede herhangi bir delta veya fark yoktur. Elbette, daha sonra nesneler deltaların paket dosyalarında depolandığı yerde paketlenebilir, ancak bu yeniden adlandırma algılamasıyla ilgili değildir.