cargo wdk new neden git deposu başlatmıyordu?

windows-drivers-rs, Microsoft'un Windows sürücülerini Rust ile yazmak için geliştirdiği platform. İçindeki cargo-wdk aracı, cargo wdk new komutuyla yeni bir sürücü projesi oluşturuyor ve bunu yaparken arka planda Cargo'nun kendi cargo new komutunu çağırıyor.

Maintainer'lardan gurry, #558 numaralı issue'da bir tutarsızlığa dikkat çekti: cargo wdk new, cargo new'e --vcs none geçiriyordu. Yani yeni sürücü projeleri git deposu olmadan oluşuyordu. Oysa cargo new'in varsayılanı git başlatmak, çünkü çoğu kullanıcının istediği bu.

Düzeltme

Değişikliğin kendisi tek satır: argüman listesinden --vcs none çıktı, böylece Cargo kendi varsayılanını uyguluyor.

// önce
let mut args = vec!["new", "--lib", &path_str, "--vcs", "none"];
// sonra
let mut args = vec!["new", "--lib", &path_str];

Davranışı kalıcı yapan test

gurry incelemede, oluşturulan projede .git klasörünün gerçekten bulunduğunu doğrulayan bir kontrol istedi. Mevcut entegrasyon testine bu satırı ekledim:

assert!(tmp_dir.join(&driver_name).join(".git").is_dir());

Bu küçük bir ekleme gibi görünse de değişikliğin asıl güvencesi o. Tek satırlık bir düzeltmeyi biri ileride fark etmeden geri alabilir; test, davranışı bir gereksinime çeviriyor.

Workspace'lerde ne oluyor?

Diğer inceleyen svasista-ms, değişikliği workspace senaryolarında elle denedi. Sonuçlar, düzeltmenin cargo new ile birebir aynı davrandığını gösterdi:

• Workspace kökünde zaten bir git deposu varsa, cargo wdk new ile eklenen sürücü paketi o depoyu kullanıyor, içine ikinci bir depo açılmıyor.
• Workspace kökünde depo yoksa, her yeni sürücü paketi kendi git deposuyla oluşuyor.

Önceki davranış ikinci durumda paketleri depo olmadan oluşturuyordu ve bu, cargo new'den farklıydı. PR, iki onayla birleşti.

Ders

Başka bir aracı saran bir araç, onun varsayılanlarını gerekçesi olmadan değiştirmemeli. Kullanıcı cargo wdk new yazarken cargo new'den ne bekliyorsa onu almalı.