git add --interactive "Düzenlediğiniz iri parça geçerli değil"

git add --interactiveKullanarak dizinime bazı değişiklikler eklemeye çalışıyorum , ancak sürekli olarak "Düzenlediğiniz önemsiz parça geçerli değil. Tekrar düzenle ..." mesajını alıyorum. E seçeneğini seçsem ve editörümü hemen kaydedip / kapatsam bile bu mesajı alıyorum. Başka bir deyişle, iri parçayı hiç düzenlemeden yama uygulanmaz.

İşte kullandığım tam örnek (küçük bir demo oluşturmaya çalışıyorum):

Orijinal dosya:

first change
second change off branch
third change off branch
second change
third change
fourth change

Yeni dosya:

Change supporting feature 1
first change
second change off branch
third change off branch
second change
third change
fourth change
bug fix 1
change supporting feature 1

git add --interactiveSadece "hata düzeltme 1" satırını dizine eklemek için nasıl kullanılacağını göstermeye çalışıyorum . Dosyada etkileşimli eklenti çalıştırarak yama modunu seçiyorum. Bana sunar

diff --git a/newfile b/newfile
index 6d501a3..8b81ae9 100644
--- a/newfile
+++ b/newfile
@@ -1,6 +1,9 @@
+Change supporting feature 1
 first change
 second change off branch
 third change off branch
 second change
 third change
 fourth change
+bug fix 1
+change supporting feature 1

Bölünmüş olarak yanıt veriyorum, ardından ilk iri parçayı uygulamak için "hayır" diyorum. İkinci iri parça, düzenlemeye çalışıyorum. Başlangıçta alt satırı silmeyi denedim - bu işe yaramadı. İri parçayı yalnız bırakmak da işe yaramıyor ve nedenini anlayamıyorum.

Bu özel örnek için, iri parçadaki satır numaralarını ayarlamanız gerekir. Satırı değiştirin:

@@ -1,6 +2,8 @@

böylece onun yerine şunu okur:

@@ -2,7 +2,8 @@

Bu gibi mi bu git-add sonrası ?

İri parçayı elle düzenlemek son derece güçlüdür, ancak daha önce hiç yapmadıysanız biraz karmaşıktır.
Akılda tutulması gereken en önemli şey: Fark, diğer girintilere ek olarak her zaman bir karakterle girintilidir.
Karakter şunlardan biri olabilir:

• boşluk (değişmemiş bir satırı belirtir),
• -hattın kaldırıldığını belirten bir
• veya +satırın eklendiğini belirten.

Başka hiçbir şey. Bir boşluk, a - veya a + olmalıdır. Başka bir şey olursa, hatalar alırsınız
(değiştirilen satır için karakter yoktur, çünkü bunlar eski satırı kaldırarak ve değiştirileni yeni olarak ekleyerek ele alınır).

En sevdiğiniz metin düzenleyicinizde diff açık olduğundan (Git'i en sevdiğiniz metin düzenleyiciyi kullanacak şekilde yapılandırdınız, değil mi?), Elde edilen farkın temiz bir şekilde uygulandığından emin olduğunuz sürece istediğiniz her şeyi yapabilirsiniz.

Ve burada hile yatıyor. Bunu daha önce hiç yapmadıysanız, Git size "Düzenlediğiniz iri parça geçerli değil. Tekrar düzenle?" Bu kadar kolay görünse de (ya da Git, ne istediğinizi çözemediği için) bunu çözemediğiniz için kendinizden çok sık nefret etmeye başlayacaksınız .

Beni sık sık şaşırtan bir şey, tek karakter girintisini unutmamdı.
Bir satırı kaldırılacak - ile işaretlerdim, ancak a ekleyen çoğu metin düzenleyicide -, daha önce orada olan alanın üzerine yazmaz. Bu, tüm satıra ek bir boşluk eklediğiniz anlamına gelir, bu da diff algoritmasının orijinal dosyadaki satırı bulamadığı / eşleştiremediği anlamına gelir, bu da Git'in size bağıracağı anlamına gelir .

Diğer bir şey de farkın hala mantıklı olması gerektiğidir. "Sense", temiz bir şekilde uygulanabileceği anlamına gelir. Tam olarak mantıklı bir fark yaratma şekliniz biraz karanlık bir sanat gibi görünüyor (en azından şu anda benim için), ancak her zaman orijinal dosyanın nasıl göründüğünü aklınızda tutmalı ve ardından -s ve + s'lerinizi buna göre planlamalısınız. Eğer yakışıklılığınızı yeterince sık düzenlerseniz, sonunda asacaksınız.

Git add -p ile ilgili şu commit konusuna da bakın .

Ortomala Lokni 'ın cevabı atıfta Joaquín Windmüller blog yayınında ' git ile işlemeye seçerek seçme değişiklikleri (veya Imma düzenlemek için iri parça) '

Satırları saymak yerine, Git'in yapmak istediği şey, söz konusu düzenlenmiş iri parçayı uygulamadan önce üst üste binen gövdeleri (biri düzenlendiğinde) birleştirmektir.
Bu, 2018'in ortasında tartışıldı ve aşağıdaki gibi senaryolardan kaçınırdı:

Eğer bir hunk'ı bölerseniz, ilk subhunk'u düzenlerseniz, takip eden bir bağlam satırını bir silme işlemine dönüştürürseniz, o zaman ikinci subhunk'u aşamalandırmaya çalışırsanız, başarısız olur.

Tabii ki buna geç kaldım, ancak yine de bu konunun geçen yıl git posta listesinde tartışıldığını ve o zamandan beri pek bir şey değişmemiş gibi göründüğünü belirtmek istedim .

Bu özel sorun, bölünmekten ve aynı iri parçayı düzenlemeye çalışmaktan kaynaklanıyor . Başlangıçta Jeff King tarafından yayınlanan sorunun altında yatan sorunun analizi esasen şudur:

Hm. Tamam anladım. "Bu fark uygulanıyor mu" işareti , bölünmüş yamanın her iki bölümünü git-apply'a besler . Ama elbette ikinci bölüm asla doğru şekilde uygulanmayacaktır çünkü içeriği ilk bölümle örtüşür, ancak onu hesaba katmaz.

Kontrolü sadece düzenlenmiş yama ile yapmak işe yarayacaktır. Ancak bu, düzenlenmiş yamanızın, bölünmüş yamanın diğer yarısını kabul edip etmemenize bağlı olarak uzun vadede uygulanamayacağını hesaba katmaz. Bunu henüz bilemeyiz, çünkü kullanıcı bize söylememiş olabilir (ilk yarıyı atlayıp düzenleme adımından sonra geri dönebilirlerdi).

Jeff, görevini her zaman başarılı olan çok pragmatik bir çözümle bitiriyor ve bu nedenle şiddetle tavsiye ediliyor:

Genel olarak, aynı iri parçayı bölmenin ve düzenlemenin doğası gereği tehlikeli olduğunu ve bu tür sorunlara yol açacağını düşünüyorum. Ve düzenleme, işlevselliğin bir üst kümesini sağladığı için, tercihinize bağlı olarak sadece düzenlemeniz ve hunk'ın ilk bölümünün uygulanmasına izin vermeniz veya etmemeniz gerektiğini düşünüyorum.

Yalnızca önceden bölünmemiş bir parçayı düzenlemeyi seçerek, satır numaralarıyla uğraşmak zorunda kalmayacaksınız.

Silmek için hazırlanmış bir satırı silmek istemediğinizde,

 first line
-second line
 third line

İkinci satırı korumak istediğiniz yerde -, tüm satırı silmek yerine (eklenmiş bir satırdan kurtulacağınız gibi) bir boşlukla değiştirdiğinizden emin olun . Git bu satırı bağlam için kullanacaktır.

Hunk başlığını da doğru şekilde değiştirmek önemlidir (örneğin @@ -1,6 +1,9 @@). Joaquin Windmuller, blog gönderisinden birinde hunk başlık düzenlemesinin sırrını açıklıyor .

Yakışıklıları düzenlemenin sırları

Hunk'ları düzenlemek ilk başta kafa karıştırıcı olabilir, git'in size verdiği talimatlar ancak başlamak için yeterli değildir.

# —||

# To remove ‘-’ lines, make them ’ ’ lines (context).

# To remove ‘+’ lines, delete them.

# Lines starting with # will be removed.

#

# If the patch applies cleanly, the edited hunk will immediately be

# marked for staging. If it does not apply cleanly, you will be given

# an opportunity to edit again. If all lines of the hunk are removed,

# then the edit is aborted and the hunk is left unchanged.

Gizli sos… satırları saymak:

• + İle başlayan bir satırı kaldırırsanız , yeni satır sayısına bir çıkarın (hunk başlığının son rakamı) .
• - ile başlayan bir satırı kaldırırsanız , yeni satır sayısına bir tane ekleyin (hunk başlığının son rakamı) .
• Diğer çizgileri (referans çizgileri) kaldırmayın.

Bu, istediğiniz parçaları seçmek için gövdeleri hızlı bir şekilde değiştirmenize izin vermelidir.

Geçenlerde bu konuyu okuyarak manuel düzenlemenin nasıl yapılacağını anladım.

Kullandığım numara şuydu: Eğer bir farkım varsa:

+ Line to add
+ Line to add
+ Line I dont want to include
+ Line I dont want to include

İşin püf noktası, istemediğim iki satırı tamamen kaldırarak ortaya çıkan farkın şöyle görünmesini sağlamaktır:

+ Line to add
+ Line to add

Bu çoğu insan için büyük olasılıkla açık olsa da, bugüne kadar benim için değildi ve sadece deneyimlerimi paylaşmam gerektiğini düşündüm. Lütfen bana bu yöntem için herhangi bir tehlike olup olmadığını söyleyin.

Satır numaralarını manuel olarak düzenleyebilirsiniz, bu bazı durumlarda kesinlikle yararlıdır. Ancak, muhtemelen ilk önce iri parçayı bölmeden bu sorunu önleyebilirdiniz.

Muhtemelen Git'in otomatik olarak seçtiği hunk'ta bir şeyi daha sonra düzenlemeniz gerekeceğini görürseniz, en iyisi bölmek, yarıyı aşamalandırmak ve sonra diğer yarıyı düzenlemek yerine bütün parçayı düzenlemek en iyisidir. Git bunu anlamak için daha iyi bir iş çıkaracaktır.

Aynı soruna çözüm arayan bu soruya geldim ve hunk'taki satır numaralarını (yukarıda önerildiği gibi) nasıl değiştireceğimi çözemedim, git benim durumumda kabul et. Bunu kullanarak yapmanın çok daha iyi bir yolunu buldum git gui. Orada sahnelemek istediğiniz farktaki satırları seçebilir, ardından sağ tıklayıp "Kaydetmeden aşamalı çizgiler" i seçebilirsiniz. Git-cola'nın da aynı işlevselliğe sahip olduğunu hatırlıyorum .

Bu hatayı aldığımda yaşadığım ek bir sorun, düzenleme dosyasını kaydettiğimde satır sonlarının değişmesiydi.

Windows kullanıyordum ve düzenlemelerim için Not Defteri kullanıyordum (yalnızca Windows satır sonlarıyla kaydediyor). Kodum Notepad ++ ile yazılmış ve Unix / Linux stili satır sonlarına sahip olacak şekilde ayarladım.

Ayarlarımı varsayılan git editörü olarak Notepad ++ olacak şekilde değiştirdiğimde, hunk üzerinde düzenlemelerimi yapabildim.

git config --global core.editor "notepad++"

Tuhaf "Düzenlenmiş iri parçanız uygulanmıyor" mesajlarının bir nedeni (muhtemelen "hata: satırda başlık olmadan yama parçası ..." gibi bir şeyle birlikte), sondaki beyaz boşluğu kaldıracak şekilde yapılandırılmışsa editörünüz olabilir. Bu açık bir şekilde, yamalar boş satırları tek boşluklu satırlar olarak kodladığından, boş satırlar içeren herhangi bir hunk, böyle bir düzenleyici ile kaydedilirse uygulanamayacağı için büyük sorunlara neden olacaktır. Dolayısıyla, gerçekte, değiştirilmemiş boş satırlar içeren herhangi bir hunk, sondaki boşlukları sıyırma açıksa, düzenlemeden sonra uygulanamaz.

Bilginize, biraz birbiriyle ilişkili bir hata alıyordum ... yukarıda önerilen talimatı izleyerek yamalı eklediğimde ... Ancak hata göstermiyordu. Tekrar tekrar aynı iri parçayı sahnelememi istiyordum ... Vim 7.4'ün eski bir sürümünü çalıştırdığımı fark ettim ... vim'i yükselttim ve şimdi beklendiği gibi çalışıyor. Umarım bu birine yardımcı olur ..