2017-08-02 15 views
7

Có một lỗi trong mã của tôi có thể được sao chép dễ dàng do thử nghiệm không thành công.git-bisect nhưng đối với N repos

Cho đến bây giờ tôi đã sử dụng git-bisect trong những trường hợp như vậy, nhưng nó chỉ hữu ích nếu chỉ có một repo git.

Trong trường hợp của tôi có 7.

Có cách nào để làm điều gì đó như git-bisect nhưng đối với kho git N?

Cập nhật

Có một "container" Repo này chứa chủ yếu là cấu hình. Nó liên quan đến một khách hàng cụ thể.

Sau đó, có một repo cho ứng dụng lõi.

Sau đó, N repos cho plugin cho ứng dụng lõi này.

Mô-đun phụ Git không được sử dụng trong ngữ cảnh này.

Update2

Đến nay tôi không sử dụng google repo tool. AFAIK nó cũng không thể chia đôi.

+1

7 kho lưu trữ? Có lý do nào cho việc này không? Họ không có điểm gì chung sao? Bạn không thể làm thứ 8, và kéo tất cả 7 người khác vào nó, kết hợp lịch sử, và sau đó bạn có thể chạy bisect ở đó? –

+1

Bảy kho lưu trữ có liên quan như thế nào? Có một số mô-đun con hoặc phụ đề của người khác không? Một số thư viện? Điều gì đang ngăn cản bạn xác định kho chứa lỗi? – Chris

+0

Tôi đã cập nhật câu hỏi giải thích tại sao có một số repo git. – guettli

Trả lời

6
  1. Trước hết: tìm trạng thái khi thử nghiệm được chuyển.

  2. Sau đó: kiểm tra xem thử đi khi quay trở lại một duy nhất của 7 kho

Ví dụ, chúng ta hãy nói rằng:

  • kiểm tra thông qua khi kho đang ở cam kết:

    A1 A2 A3 A4 A5 A6 A7 
    
  • kiểm tra không được chuyển khi tất cả người gửi lại ies đang ở TRỤ mới của họ:

    B1 B2 B3 B4 B5 B6 B7 
    

thử để xem nếu thử nghiệm đi trong các cấu hình sau:

A1 B2 B3 B4 B5 B6 B7 
B1 A2 B3 B4 B5 B6 B7 
B1 B2 A3 B4 B5 B6 B7 
etc ... 

Nếu bạn quản lý để cô lập một repo đơn theo cách này: bạn chỉ cần bisect trên đó.

+0

Nếu bạn không thể giảm xuống một repo đơn lẻ, hãy thêm nhận xét – LeGEC

+0

Có, thuật toán này sẽ hoạt động. – guettli

Các vấn đề liên quan