Perforce kullanıcıları için Git

Perforce'u birkaç yıldır kullanıyorum. Kişisel kodum için git kullanmaya geçmek istiyorum, ancak gördüğüm git öğreticilerinin tümü ya tam bir kaynak denetimi n00b (bu da onları inanılmaz derecede sıkıcı yapıyor) ya da alışkın olduğunuzu varsayıyor svn (ben değilim).

P4'ü biliyorum ve ayrıca dağıtılmış bir kaynak kontrol sisteminin arkasındaki fikri de anlıyorum (bu yüzden bir satış konuşmasına ihtiyacım yok, teşekkürler). İstediğim şey, p4 komutundan eşdeğer git komutlarına bir çeviri tablosu ve p4 eşdeğeri olmayan "olmadan yaşayamaz" komutlarıdır.

Her p4 kullanıcısının p4'ün farklı bir alt kümesini kullandığından şüphelendiğim için, p4'te düzenli olarak yaptığım, git'te yapmak istediğim ve baktığım belgelerden hemen anlaşılmayan bazı şeyler var. :

1. tek bir istemcide birden çok bekleyen değişiklik listesi oluşturun. ( p4 change)
2. bekleyen değişiklik listesini düzenleyin. (ayrıca p4 change)
3. tüm bekleyen değişiklik listelerimin bir listesini gör ( p4 changes -s pending)
4. Müvekkilim değişti tüm dosyaları listesi ( p4 opened) veya bekleyen bir değişiklik listesi içinde ( p4 describe)
5. bekleyen değişiklik listesinin bir farkını gör (bunun için p4 diffve kullanan bir sarmalayıcı komut dosyası kullanıyorum p4 describe)
6. belirli bir dosya için hangi gönderilmiş değişiklik listelerinin hangi satırları etkilediğini görün ( p4 annotate)
7. belirli bir dosya için dosyayı etkileyen değişiklik listelerinin açıklamalarının bir listesine bakın ( p4 log)
8. bekleyen değişiklik listesi gönderin ( p4 submit -c)
9. bekleyen değişiklik listesini iptal et ( p4 revert)

Bunların çoğu "değişim listeleri" etrafında dönüyor. "değişiklik listesi" p4 terminolojisidir. Git eşdeğeri terimi nedir?

Görünüşe göre dallar, git kullanıcılarının p4'ün değişiklik listesi dediği şey yerine kullandıkları şey olabilir. Biraz kafa karıştırıcı, çünkü p4'te dal adı verilen bir şey de var, ancak bunlar sadece belli belirsiz ilişkili kavramlar gibi görünüyor. (Her zaman p4'ün dal kavramının oldukça tuhaf olduğunu düşünmeme rağmen, yine bir dalın klasik RCS konseptinden farklıdır.)

Her neyse ... Git'in dalları ile normalde p4 değişim listelerinde yaptığım şeyi nasıl başaracağımdan emin değilim. 4. sayfada şöyle bir şey yapabilirim:

$ p4 edit a.txt
$ p4 change a.txt
Change 12345 created.

Bu noktada a.txt içeren bir değişiklik listem var. Açıklamayı düzenleyebilir ve değişiklik listesini göndermeden çalışmaya devam edebilirim. Ayrıca, kodun başka bir katmanındaki bir hata düzeltmesi gibi başka dosyalarda bazı değişiklikler yapmam gerektiği ortaya çıkarsa, bunu aynı istemcide yapabilirim:

$ p4 edit z.txt
$ p4 change z.txt
Change 12346 created.

Şimdi aynı istemcide iki ayrı değişiklik listem var. Bunlar üzerinde aynı anda çalışabilirim ve "aralarında geçiş" yapmak için hiçbir şey yapmam gerekmiyor. Taahhüt zamanı geldiğinde, bunları ayrı ayrı gönderebilirim:

$ p4 submit -c 12346  # this will submit the changes to z.txt
$ p4 submit -c 12345  # this will submit the changes to a.txt

Bunu git'te nasıl çoğaltacağımı çözemiyorum. Deneylerimden, git addmevcut dalla ilişkili görünmüyor . Anlayabildiğim kadarıyla, o sırada hangi dalda olursam olayım git commit, yaptığım tüm dosyaları ne zaman işleyeceğim git add:

$ git init
Initialized empty Git repository in /home/laurence/git-playground/.git/
$ ls
a.txt  w.txt  z.txt
$ git add -A .
$ git commit
 Initial commit.
 3 files changed, 3 insertions(+), 0 deletions(-)
 create mode 100644 a.txt
 create mode 100644 w.txt
 create mode 100644 z.txt
$ vi a.txt z.txt 
2 files to edit
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   a.txt
#   modified:   z.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git branch aardvark
$ git checkout aardvark
M   a.txt
M   z.txt
Switched to branch 'aardvark'
$ git add a.txt 
$ git checkout master
M   a.txt
M   z.txt
Switched to branch 'master'
$ git branch zebra
$ git checkout zebra
M   a.txt
M   z.txt
Switched to branch 'zebra'
$ git add z.txt 
$ git status
# On branch zebra
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   a.txt
#   modified:   z.txt
#
$ git checkout aardvark
M   a.txt
M   z.txt
Switched to branch 'aardvark'
$ git status
# On branch aardvark
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   a.txt
#   modified:   z.txt

Bu örnekte, aardvark ve zebra dalları tam olarak aynı değişiklik setini içeriyor gibi görünüyor ve çıktısına göre git statusikisinde de bir commit yapmanın aynı etkiye sahip olacağı görülüyor. Yanlış bir şey mi yapıyorum?

Perforce'ı pek kullanmadım, bu yüzden bu tam olarak 1: 1 çeviri olmayabilir. Sonra yine git ve mercurial gibi dağıtılmış kaynak kontrol sistemleri farklı bir iş akışına sahiptir, bu nedenle gerçekten 1: 1 çeviri yoktur (ve olmamalıdır). Her neyse, işte:

• Birden çok bekleyen değişiklik listesi oluşturun -> Bunun yerine dalları kullanın. Git dallarında hafif ve hızlıdır, oluşturulması bir saniyeden az sürer ve genellikle birleştirilmesi iki saniyeden az sürer. Sık sık dallanma ve yeniden ödeme yapmaktan korkmayın.

  git branch new-branch-name
  git checkout new-branch-name
  

  Veya hepsini tek bir satırda yapın:

  git checkout -b new-branch-name
  

• Tüm bekleyen değişiklik listelerinin bir listesini görün -> Birden çok bekleyen değişiklik listesinin eşdeğeri birden çok dal olduğundan, yalnızca dalları görüntüleyin:

  git branch
  

  Uzak şubeleri de görüntülemek istiyorsanız:

  git branch -a
  

  Başarılı bir birleştirmeden sonra bir dalı hemen silmek iyi bir uygulama olarak kabul edilir, böylece hangi dalın birleştirilmeyi beklediğini ve hangilerinin zaten birleştirildiğini takip etmek zorunda kalmazsınız.

• Tüm değiştirilen dosyaları listele -> Belirli bir daldaki tek bir bekleyen "değişiklik listesi" için git, dizin veya önbellek kavramına sahiptir. Bir değişiklik yapmak için önce bu dizine dosya eklemelisiniz. Bu, hangi dosya grubunun tek bir değişikliği temsil ettiğini manuel olarak seçmenize veya ilgisiz dosyaları göz ardı etmenize olanak tanır. Bu dizine hangi dosyaların eklendiğini veya eklenmediğini görmek için şunu yapın:

  git status
  

• Bekleyen bir değişiklik listesinin farkına bakın -> Bunun iki bölümü vardır. İlk olarak, çalışma dizini ile dizin arasında bir fark görürsünüz:

  git diff
  

  Ancak, şimdi yazdıklarınızla son kayıt arasındaki farkı bilmek istiyorsanız, gerçekten çalışma dizini + dizin ve HEAD arasında bir fark olmasını istiyorsunuz:

  git diff HEAD
  

• Belirli bir dosya için, hangi gönderilmiş değişiklik listelerinin hangi satırları etkilediğini görün -> Bu kolaydır:

  git blame filename
  

  hatta daha da iyisi, pencereleme ortamındaysanız:

  git gui blame filename
  

  Git gui'nin dosyayı ayrıştırması daha uzun sürer (C yerine tcl ile yazılmıştır), ancak bir commit kimliğine tıklayarak geçmişe "zamanda yolculuk" yeteneği de dahil olmak üzere birçok düzgün özelliğe sahiptir. Keşke geleceğe "zamanda yolculuk" için bir özellik uygulasalar, böylece belirli bir hatanın sonunda nasıl çözüleceğini öğrenebilirim ;-)

• Belirli bir dosya için, dosyayı etkileyen değişiklik listelerinin açıklamalarının bir listesine bakın -> ayrıca kolay:

  git log filename
  

  Ancak git log, bundan çok daha güçlü bir araçtır. Aslında, kişisel komut dosyalarımın çoğu, depoyu okumak için git günlüğünün dışına atıyor. Man sayfasını okuyun.

• Bekleyen bir değişiklik listesi gönderin -> Ayrıca kolay:

  git commit
  

Tipik git iş akışımı görmek için önceki bir soruya verdiğim cevaba bakın: Git Öğrenmek. Doğru yolda olup olmadığımı bilmem gerekiyor

Özetlediğim iş akışını takip ederseniz, gitk gibi araçların çok daha değerli olduğunu göreceksiniz çünkü bu, değişiklik gruplarını net bir şekilde görmenize izin veriyor.

Ek cevap:

Git çok esnektir ve tarif ettiğiniz şeyi yapmanın birkaç yolu vardır. Unutulmaması gereken şey, üzerinde çalıştığınız her özellik için her zaman yeni bir dal başlatmaktır. Bu, ana dala dokunulmadığı anlamına gelir, böylece hata düzeltmeleri yapmak için her zaman ona geri dönebilirsiniz. Git one'da çalışmak neredeyse her zaman şununla başlamalıdır:

git checkout -b new-feature-a

Artık a.txt dosyasını düzenleyebilirsiniz. Aynı anda başka bir özellik üzerinde çalışmak için şunları yapın:

git checkout master
git checkout -b new-feature-z

Artık z.txt dosyasını düzenleyebilirsiniz. A.txt dosyasına geri dönmek için:

git checkout new-feature-a

Ama bekleyin, new-feature-z'de değişiklikler var ve git, dalları değiştirmenize izin vermiyor. Bu noktada iki seçeneğiniz var. İlki en basit olanıdır, tüm değişiklikleri geçerli şubeye uygulayın:

git add .
git commit
git checkout new-feature-a

Bunu tavsiye ederim. Ancak kodu işlemeye gerçekten hazır değilseniz, geçici olarak saklayabilirsiniz:

git stash

Artık new-feature-a dalına geçebilirsiniz. Üzerinde çalıştığınız koda geri dönmek için zulayı açın:

git checkout new-feature-z
git stash pop

Her şey tamamlandığında, tüm değişiklikleri ana olarak birleştirin:

git merge --no-ff new-feature-a
git merge --no-ff new-feature-z

Birleştirmeler çok hızlı ve kolay olduğu için (kolay çünkü anlaşmazlıklar çok nadirdir ve anlaşmazlık çözümü, biri gerçekleştiğinde çok zor değildir) her şey için git'teki dalları kullanırız.

Diğer kaynak denetim araçlarında görmediğiniz, git'te yaygın olarak kullanılan dalların başka bir örneği (belki mercurial hariç):

Yapılandırma dosyalarınızı geliştirme ortamınızı yansıtacak şekilde değiştirmeye devam etmeniz mi gerekiyor? Sonra bir dal kullanın:

git checkout -b dev-config

Şimdi en sevdiğiniz düzenleyicide yapılandırma dosyalarınızı düzenleyin ve değişiklikleri uygulayın:

git add .
git commit

Artık her yeni dal, master yerine dev-config dalından başlayabilir:

git checkout dev-config
git checkout -b new-feature-branch

Bitirdiğinizde, etkileşimli yeniden taban kullanarak dev-config'deki düzenlemeleri new-feature-branch'tan kaldırın:

git rebase -i master

İstemediğiniz taahhütleri silin ve ardından kaydedin. Artık özel yapılandırma düzenlemeleri olmayan temiz bir dalınız var. Ustaya geri dönme zamanı:

git checkout master
git merge --no-ff new-feature-branch
# because master have changed, it's a good idea to rebase dev-config:
git checkout dev-config
git rebase master

git rebase -iTüm değişiklikler aynı dosyada gerçekleştiğinde bile düzenlemeleri kaldırmanın işe yaradığına dikkat edilmelidir . Git, dosya içeriğini değil değişiklikleri hatırlar *.

* not: aslında, teknik olarak tamamen doğru değil, ancak bir kullanıcı olarak böyle hissettiriyor

Daha fazla ek cevap:

Dolayısıyla, yorumlarınızdan iki dalın aynı anda var olmasını istediğiniz gibi görünüyor, böylece birleşik kodun nasıl çalıştığını test edebilirsiniz. Bu, dalların gücünü ve esnekliğini göstermenin iyi bir yoludur.

İlk olarak, ucuz dallanma ve değiştirilebilir geçmişin iş akışınız üzerindeki etkisi hakkında bir söz. CVS ve SVN kullanırken her zaman taahhütte biraz isteksizdim. Bunun nedeni, kararsız kod işlemenin kaçınılmaz olarak diğer insanların çalışma kodunu bozacağıdır. Ama git ile bu korkuyu kaybettim. Bunun nedeni, git'te başkalarının değişikliklerimi ustalaşmak için birleştirene kadar alamayacaklarıdır. Artık yazdığım her 5 satırda bir kod işlerken buluyorum kendimi. Taahhüt etmek için mükemmel bir öngörüye ihtiyacınız yok. Sadece zihniyetinizi değiştirmeniz gerekir: commit-to-branch == add-to-changeset, merge-to-master == commit-changeset.

Öyleyse örneklere geri dönelim. İşte bunu nasıl yapacağım. Bir şubeniz olduğunu new-feature-zve onu test etmek istediğinizi varsayalım new-feature-a. Sadece test etmek için yeni bir şube oluştururdum:

# assume we are currently in branch new-feature-z
# branch off this branch for testing
git checkout -b feature-z-and-feature-a
# now temporarily merge new-feature-a
git merge --no-ff new-feature-a

Şimdi test edebilirsiniz. Feature-z'nin özellik-a ile çalışması için bir şeyi değiştirmeniz gerekiyorsa, o zaman bunu yapın. Eğer öyleyse, değişiklikleri ilgili şubeye geri birleştirebilirsiniz. Kullanımgit rebase -iBirleştirmeden alakasız değişiklikleri kaldırmak için .

Alternatif olarak, git rebase'i, new-feature-z'nin temelini new-feature-a'ya işaret edecek şekilde geçici olarak değiştirmek için de kullanabilirsiniz:

# assume we are currently in branch new-feature-z
git rebase new-feature-a

Şimdi dallanma geçmişi değiştirildi, böylece new-feature-z, master yerine new-feature-a'ya dayanacak. Şimdi test edebilirsiniz. Bu dalda yapılan tüm değişiklikler new-feature-z dalına ait olacaktır. Yeni özellik-a'yı değiştirmeniz gerekirse, yeni değişiklikleri almak için ona geri dönün ve geri ödemeyi yapın:

git checkout new-feature-a
# edit code, add, commit etc..
git checkout new-feature-z
git rebase new-feature-a
# now new-feature-z will contain new changes from new-feature-a

İşiniz bittiğinde, yeni özellik-a'daki değişiklikleri kaldırmak için ana bilgisayara geri dönmeniz yeterlidir:

# assume we are currently in branch new-feature-z
git rebase master

Yeni bir şube kurmaktan korkmayın. Tek kullanımlık bir dal başlatmaktan korkmayın. Dalları atmaktan korkmayın. Ve birleştirme == gönder ve kaydet == değişikliklere ekle kümesinden beri sık sık taahhüt etmekten korkmayın. Unutmayın, commit bir geliştiricinin nihai geri alma aracıdır.

Oh, ve başka bir şey, git silinen dallarda hala deponuzda var. Dolayısıyla, daha sonra yanlışlıkla bir şeyi sildiyseniz, her şeyden sonra yararlı olduğunu fark ettiğiniz bir şeyi geçmişte arayarak her zaman geri alabilirsiniz. Bu yüzden dalları atmaktan korkmayın.

Gerçek bir kopya kâğıdı oluşturmak için yeterli p4 deneyimim yok, ancak geri dönülecek en azından bazı benzerlikler var. Bir p4 "değişiklik kümesi" bir git "commit" dir.

Yerel çalışma alanınızda yapılan değişiklikler ile "dizine" eklenir git addve dizin daha sonra işlenir git commit. Yani dizin, tüm niyet ve amaçlar için bekleyen değişiklik listenizdir.

Değişikliklere git diffve ile bakarsınız git status, burada git diffgenellikle çalışma alanı ve dizin git diff --cachedarasındaki değişiklikleri gösterir , ancak dizin ve depo arasındaki değişiklikleri gösterir (= bekleyen değişiklik listeniz).

Daha ayrıntılı bilgi için, http://progit.org/book/ tavsiye ederim . Genel olarak sürüm kontrolünü bildiğiniz için, muhtemelen çoğunu gözden geçirebilir ve git'e özgü bilgileri çıkarabilirsiniz ...

Git dallarıyla tam olarak aynı olmayan "değişim listesi" konseptinin eksikliğinden sizin gibi acı çekiyorum.

Bu değişiklik listesindeki dosyaların listesiyle bir değişiklik listesi dosyası oluşturacak küçük bir komut dosyası yazardım.

Sadece git commit -a @ change_list_contents.txt ve ardından "git commit" çağırarak belirli bir değişiklik listesini göndermek için başka bir komut

Umarım yardımcı olur, Elias

Git'te iş akışınızın bir parçasını oluşturabilecek daha hafif bir alternatif var; git evreleme alanını kullanarak.

Sık sık sadece değişiklik yapıyorum ve sonra birkaç işlem olarak gönderiyorum (örneğin, hata ayıklama ifadeleri ekliyorum, refactor, aslında bir hatayı düzeltiyorum). Performans değişiklik listelerinizi oluşturmak, ardından değişiklikler yapmak, sonra göndermek yerine, sadece değişikliklerinizi yapabilir ve sonra bunları nasıl göndereceğinizi seçebilirsiniz (isteğe bağlı olarak git aşamalandırma alanını kullanarak).

Komut satırından belirli dosyaları şu şekilde yürütebilirsiniz:

git commit a.txt
git commit z.txt

Veya önce dosyaları açıkça hazırlayarak:

git add a.txt
git commit
git add z.txt
git commit

git gui, hazırlama alanında bir commit oluşturmak için dosyaların içinden satırları veya hunksları seçmenize izin verir. Bir dosyada farklı kayıtlarda olmasını istediğiniz değişiklikler varsa bu çok kullanışlıdır. Git'ten perforce'a geçtim ve bu gerçekten özlediğim bir şey.

Bu iş akışıyla ilgili akılda tutulması gereken küçük bir uyarı var. Bir dosyada A ve B değişiklikleri yaparsanız, dosyayı test edin ve ardından A işlemini tamamlarsanız, bu işlemi test etmemişsinizdir (B'den bağımsız olarak).

Bu, sorunuzu özel olarak yanıtlamaz, ancak perforce'un 2 Kullanıcılı, 5 Çalışma Alanı sürümünün perforce web sitesinden indirilip kullanılmasının ücretsiz olduğunun farkında olup olmadığınızı bilmiyorum .

Bu sayede dilerseniz kişisel projeleriniz için evde perforce kullanabilirsiniz. Bir sıkıntısı, biraz sınırlayıcı olabilen 5 çalışma alanıdır, ancak ev kullanımı için uygun bir performansa sahip olmak oldukça inanılmazdır.

Hem Perforce hem de git'i oldukça kapsamlı bir şekilde kullandım, git ile Perforce değişiklik listelerine yaklaşmanın tek bir yolu var.

Anlaşılması gereken ilk şey, bu işlevselliği git'te tam bir kluge olmayacak şekilde doğru bir şekilde uygulamak, örneğin onu dallara ayırmaya çalışmak, aşağıdaki değişikliği gerektireceğidir: git, tek bir dal için birden fazla evreleme alanı gerektirecektir. .

Perforce değişiklik listeleri, git'te eşdeğeri olmayan bir iş akışına izin verir. Aşağıdaki iş akışını göz önünde bulundurun:

Check out a branch
Modify file A and add it to changelist 1
Modify file B and add it to changelist 2

Bunu git'teki dalları kullanarak yapmaya çalışırsanız, biri dosyada değişikliklere sahip A, diğeri dosyada değişikliklere sahip Bancak hem dosyalarda Ahem Bde Aynı zaman.

Görebildiğim en yakın yaklaşım kullanmaktır git add . -pkullanmak ve daha sonra 'a've'd' tüm dosyaları seçmek veya reddetmek alt komutlarını kullanmaktır. Bununla birlikte, bu tamamen aynı değildir ve buradaki fark, iki sistemin genel işleyiş tarzındaki temel bir uyumsuzluktan kaynaklanmaktadır.

Git (ve bu tartışma için önemli olmadığı için yıkım), önceden kimseye söylemeden bir dosyanın değiştirilmesine izin verir. Sadece bir dosyayı değiştirirsiniz ve değişiklikleri uyguladığınızda git'in hepsini düzenlemesine izin verirsiniz. Perforce, değişikliklere izin verilmeden önce bir dosyayı aktif olarak teslim almanızı gerektirir ve bu nedenle değişiklik listelerinin var olması gerekir. Esasen, Perforce, değiştirmeden önce dizine bir dosya eklemenizi gerektirir. Bu nedenle, Perforce'da birden fazla değişiklik listesi gerekliliği ve ayrıca git'in eşdeğeri olmamasının nedeni. Onlara ihtiyacı yok.

Git 2.27 (Q2 2020) ile, " git p4" dört yeni kancayı " --no-verify" ve ayrıca onları atlama seçeneğini " " (ve mevcut " p4-pre-submit" kancayı) öğrendi .

Bkz 1ec4a0a işlemek , 38ecf75 işlemek , cd1e0dc tamamlama (muhtemelen 2020 14 Şubat) ve 4935c45 işlemek , aa8b766 işlemek , 9f59ca4 işlemek , 6b602a2 tamamlama ile (11 Şubat 2020 yılında) Ben Keene ( seraphire) .
^{(Göre Birleştirilmiş - Junio Cı Hamano gitster- içinde 5f2ec21 tamamlama 2020 22 Apr)}

git-p4: p4 gönderme kancaları ekle

^{İmza: Ben Keene}

Git komutu " commit", commit komutunun davranışını değiştirmeyi destekleyen bir dizi kancayı destekler.

git-p4.pyProgram sadece "tek varolan kanca vardır p4-pre-submit".

Bu komut işlemin erken safhalarında gerçekleşir.

P4 değişiklik listesi metnini programlı olarak değiştirmek için işlem akışında hiçbir kanca yoktur.

git-p4.pyGönder seçeneğine 3 yeni kanca ekler .

Yeni kancalar:

• p4-prepare-changelist- Değişiklik listesi dosyası oluşturulduktan sonra bu kancayı çalıştırın. Seçenek ayarlansa
  bile kanca çalıştırılacaktır --prepare-p4-only.
  Bu kanca --no-verify, mevcut davranışa uygun seçeneği yoksayar .git commit .

• p4-changelist- Kullanıcı değişiklik listesini düzenledikten sonra bu kancayı çalıştırın.
  Kullanıcı --prepare-p4-onlyseçeneği seçtiyse bu kancayı çalıştırmayın .
  Bu kanca onurlandıracak--no-verify , kurallarına uyarakgit commit .

• p4-post-changelist- P4 gönderme işlemi başarıyla tamamlandıktan sonra bu kancayı çalıştırın.
  Bu kanca hiçbir parametre almaz ve --no-verifyseçeneğe bakılmaksızın yürütülür .

Dönüş değeri kontrol edilmeyecektir.

Yeni kanca için çağrılar: p4-prepare-changelist, p4-changelistve p4-post-changelisttüm deneme-nihayet bloğunun içinde çağrılmalıdır.

Git 2.28'den (Q3 2020) önce, " --prepare-p4-only" seçeneğinin bir değişiklik kümesini tekrar oynadıktan sonra durması, ancak devam etmesi gerekiyor (yanlışlıkla?)

Bkz. Commit 2dfdd70 (12 Mayıs 2020), Ben Keene ( seraphire) .
^{(Göre Birleştirilmiş - Junio Cı Hamano gitster- içinde 7a8fec9 tamamlama 2020 02 Haz)}

git-p4.py: --prepare-p4-onlybirden çok kaydetmeyle ilgili hatayı düzelt

^{İmza: Ben Keene}

Seçenekle git p4 submitbirlikte kullanıldığında --prepare-p4-only, program tek bir p4 değişiklik listesi hazırlamalı ve kullanıcıya daha fazla işlemin beklemede olduğunu bildirmeli ve ardından işlemi durdurmalıdır.

p4-changelistKanca özelliğinde, programın tüm bekleyen değişiklik listelerini aynı anda denemeye ve işlemeye devam etmesine neden olan bir hata ortaya çıktı .

Kaydetme başarılı olduğunda işlev applyCommitgeri döner Trueve program devam etmelidir.
Ancak, isteğe bağlı bayrak--prepare-p4-only ayarlandığında, program ilk uygulamadan sonra durmalıdır.

Yöntemi --prepare-p4-onlybaşarıyla tamamladıktan sonra bayrağı kontrol etmek için P4Submit'in çalıştırma yöntemindeki mantığı değiştirin applyCommit.

1'den fazla kayıt P4'e gönderilmeyi bekliyorsa, yöntem P4 değişiklik listesini düzgün bir şekilde hazırlar, ancak yine de 1 çıkış koduyla uygulamadan çıkacaktır.

Geçerli dokümantasyon çıkış kodu bu durumda ne olması gerektiğini tanımlamaz.