bản sao git-svn | chi nhánh giả

Question

Tôi đã sử dụng lệnh sau để sao chép svn repo vào git và sau khi thực hiện nó, tôi thấy một số nhánh giả.

git svn clone [SVN repo URL] --no-metadata -A authors-transform.txt --stdlayout ~/temp

git branch -a

*(no branch) 
    master 
    remotes/abc-1.3.x 
    remotes/abc-1.3.x@113346 
    remotes/abc-1.3.x@541512 
    remotes/branch_test_script 
    remotes/tags/modules-1.2 
    remotes/tags/modules-1.2@113346 
    remotes/tags/modules-1.2@516265 
    remotes/tags/release-1.1 
    remotes/tags/release-1.1@113346 
    remotes/tags/release-1.1@468862 
    remotes/trunk 

chi nhánh thực tế tạo ra trong svn là abc, branch_test_script, module và phát hành. Ai đó có thể giúp hiểu được 'abc-1.3.x@113346', 'abc-1.3.x@541512' ... 'release-1.1@468862' vv nào không?

Làm cách nào để loại bỏ các nhánh giả mạo này/chúng có ý nghĩa gì?

Cảm ơn,
Gayathri

Answer 1

tl; dr:

git svn tạo ra những "@" - chi nhánh nếu chi nhánh (hoặc thẻ) được tạo ra cho một thư mục con (hoặc cho một thư mục mà không được theo dõi bởi git-svn). Sẽ luôn có một nhánh "thông thường" có cùng tên, nhưng không có hậu tố "@". "@" - chi nhánh chỉ tồn tại như một điểm phân nhánh cho nhánh thông thường.

---

Lưu ý: Tôi đã gửi bản vá cho việc này; phiên bản chỉnh sửa của lời giải thích này hiện là một phần của trang chính thức git svn, như một phần mới "XỬ LÝ CÁC CHI NHÁNH SVN" (kể từ Git 1.8.1).

---

Trong Subversion, ngành và các thẻ chỉ là bản sao của một cây thư mục, vì vậy nó có thể (mặc dù thường nản chí) để tạo ra một chi nhánh từ một thư mục mà bản thân nó không một chi nhánh (hoặc thân) là. Ví dụ, bằng cách sao chép/trunk/foo vào/branch/bar, thay vì sao chép/trunk (một "thư mục con", để nói), hoặc bằng cách sao chép một thư mục nằm bên ngoài cấu trúc trunk/tags/branch (đó là có thể trong SVN).

Trong git, tuy nhiên, nhánh luôn dành cho toàn bộ repo, các thư mục con không tồn tại. git svn do đó sử dụng giải pháp thay thế. Nếu nó phát hiện một chi nhánh đã được sao chép từ một thư mục không phải là chính nó được theo dõi như là một chi nhánh của git-svn, nó sẽ tạo ra một lịch sử mới. Ví dụ, đối với một chi nhánh thư mục con ở đâu/trunk/foo được sao chép vào/chi nhánh/bar trong r1234, nó sẽ tạo ra:

• Một git mới cam kết cho mỗi phiên bản SVN từ r1233 trên ngược (lưu ý số lượng là bản sửa đổi cuối cùng trước khi chi nhánh được tạo). Các cây của các cam kết này sẽ chỉ chứa thư mục con được phân nhánh. Vì vậy, đối với mỗi sửa đổi từ r1233 trở đi, thường sẽ có hai cam kết git, một với toàn bộ cây (được tạo ra khi git-svn xử lý lịch sử của trunk), và những cái mới.
• Chi nhánh giả gọi là "bar @ 1233" (tên chi nhánh @ bản sửa đổi), có sẵn cho cam kết được tạo từ r1233 ở trên.
• Cam kết từ r1234, cam kết đã tạo chi nhánh. Cam kết này sẽ có nhánh trên là tổ tiên (chỉ) của nó.
• Chi nhánh được gọi là "thanh", trỏ đến cam kết thứ hai.

Bằng cách đó, cho thanh chi nhánh thư mục con, bạn sẽ có hai chi nhánh tại git

• thanh @ 1233, đại diện cho nhà nước của các kho lưu trữ mà chi nhánh đã được tạo ra từ
• thanh, đại diện cho chi nhánh

Tôi không chắc chắn lý do tại sao nhánh giả này được tạo. Tôi nghĩ rằng nó được thực hiện để đại diện cho thông tin về việc sửa đổi chi nhánh được phân nhánh từ, và để có một lịch sử hoàn chỉnh cho chi nhánh.

---

Lưu ý rằng toàn bộ cơ chế này có thể được tắt bằng cách sử dụng cờ --no-follow-parent. Trong trường hợp đó, mỗi nhánh SVN sẽ dẫn đến một nhánh git chỉ với các commit từ thư mục nhánh SVN. Mỗi nhánh sẽ không được kết nối với phần còn lại của lịch sử, và sẽ có cam kết gốc riêng của nó, tương ứng với cam kết đầu tiên trong nhánh.

Answer 2

tôi đã như vậy kỳ lạ gọi là cành quá khi tôi nhân bản repo SVN của tôi vào một repo Git.

Sau khi xem xét các ngành dự kiến ​​(trong trường hợp của bạn modules-1.2, abc-1.3.x, branch_test_script và release-1.1) Tôi nhận thấy rằng @revisionnumber chi nhánh là không có gì khác hơn so với cam kết trong chi nhánh tiền tố của họ.

Nếu bạn muốn thực hiện thủ công, hãy mở gitk trên chi nhánh abc-1.3.x và xác minh rằng abc-1.3.x@113346 và abc-1.3.x@541512 hiển thị trong lịch sử của chi nhánh đó. Nếu có, bạn có thể xóa nhánh tương ứng.

Điều này có thể hơi cồng kềnh nếu bạn có nhiều nhánh hoặc nhiều cam kết duyệt qua.

cách tự động: hỏi git để làm điều đó cho bạn:

git branch -r --contains abc-1.3.x@113346 

sẽ echo (hoặc ít nhất nên)

abc-1.3.x 
abc-1.3.x@113346 
abc-1.3.x@541512 

Điều này có nghĩa rằng bạn có thể xóa một cách an toàn abc-1.3.x@113346 bởi vì nó chứa trong abc-1.3.x:

git branch -r -d abc-1.3.x@113346 

Do lịch sử tuyến tính của SVN, tất nhiên nó cũng chứa nó là cam kết (mới hơn) 541512.

---

Side lưu ý:
Bạn có thể thấy rằng các thẻ SVN của bạn không thực sự chuyển đổi sang thẻ Git, ngành Git bản địa. Điều này có thể đạt được bằng cách sử dụng svn2git để sao chép SVN repo vào một repo Git.