Sửa kho git-svn sau khi sửa đổi Subversion lịch sử đã thay đổi

Question

Tôi sử dụng git-svn để giữ bản sao của kho lưu trữ Subversion được chia sẻ. Gần đây, một người nào đó đã chỉnh sửa thông báo cam kết sửa đổi (a lathis SO question) sau khi tôi đã sửa đổi bản sửa đổi đó git svn fetch. Làm thế nào tôi có thể sửa bản sao Git của tôi để có thông điệp cam kết chính xác?

Tôi đã mong đợi git svn reset theo sau là git svn fetch để nạp lại cam kết này và cập nhật mọi thứ, để tôi chỉ cần sửa các nhánh địa phương của tôi, nhưng điều đó dường như không thực sự làm gì; git svn fetch không tìm nạp lại các cam kết mà tôi đã đặt lại.

(Vâng, tôi nghĩ rằng việc thay đổi cam kết thông báo là một ý tưởng tồi, nhưng đó không phải là điều mà tôi có thể kiểm soát.)

Cập nhật: Tôi đã thử các quá trình đó sleske đề xuất (trong thực tế, tôi đã cố gắng nó trước khi đặt câu hỏi, nhưng tôi chỉ cố gắng một lần nữa chỉ trong trường hợp), nhưng không có may mắn. Tôi nhận được kết quả như dưới đây:

me_and@centos ~/code ((358a2dd...)) Fri 16 Jan 15:31:27 
$ git svn reset -p 55102 
r55094 = 25d126219f7eeddfc7d0842704c7efcc0443dd70  (refs/remotes/origin/branchname) 

me_and@centos ~/code ((358a2dd...)) Fri 16 Jan 15:33:06 
$ git svn fetch 

me_and@centos ~/code ((358a2dd...)) Fri 16 Jan 15:33:08 
$ 

Không có đầu ra từ git svn fetch (hoặc có nếu đã có cam kết kể từ khi tôi cuối cùng chạy nó, nhưng nó chỉ lấy các cam kết mới, không refetching những cái cũ), và đặc biệt không có thông báo rereading như trong ví dụ của sleske.

Trong trường hợp nó có liên quan, tôi đang sử dụng Git v2.0.4.

Cập nhật 2: Hơi redacted .git/config dưới đây:

[core] 
    repositoryformatversion = 0 
    filemode = true 
    bare = false 
    logallrefupdates = true 
[svn-remote "svn"] 
    url = http://server/repos/repo 
    fetch = trunk:refs/remotes/origin/trunk 
    branches = branches/*:refs/remotes/origin/* 
    tags = tags/v10/*:refs/remotes/origin/tags/* 
    tags = tags/v11/*:refs/remotes/origin/tags/* 
    tags = tags/v12/*:refs/remotes/origin/tags/* 
    tags = tags/v13/*:refs/remotes/origin/tags/* 

tôi không sẽ đăng toàn bộ sản lượng git branch -avv, bởi vì có rất nhiều của nó, nhưng đó là nơi nó được thực sự thú vị, vì vậy tôi ll đăng danh sách tất cả mọi thứ tôi đã làm:

1. Tôi đã thanh toán chi nhánh khác với chi nhánh có lỗi. Chạy git svn reset không có sự khác biệt: remotes/origin/branchname tiếp tục trỏ đến cam kết gần đây hơn. Không ngạc nhiên, git svn fetch không làm gì cả.

2. Tôi đã kiểm tra remotes/origin/branchname và chạy lại git svn reset. Điều này làm việc: remotes/origin/branchname chỉ vào cha của cam kết duff.

3. Tôi chạy git svn fetch. Điều này hoàn toàn không có gì: không có cam kết nào được tìm nạp và remotes/origin/branchname không di chuyển.

4. Tôi đã tạo một vài cam kết giả trên nhánh đó trong kho lưu trữ Subversion (một tệp được thêm vào tệp trống, tệp tiếp theo đã xóa nó một lần nữa), sau đó chạy git svn fetch again.

   Đây là nơi nó thực sự kỳ lạ: cam kết duff không được tải lại. Thay vào đó, tìm nạp bắt đầu tại cam kết, nơi tôi đã thêm tệp giả, báo cáo "Chỉ mục không khớp" trong quá trình.Running git show trên cam kết thêm tệp giả cho thấy nó có tất cả các khác biệt giữa cam kết mà tôi đặt lại và giả cam kết.

   Bây giờ, chạy git log --graph --decorate --pretty=oneline --abbrev-commit HEAD origin/branchname trông như thế này:

   * 7b12bbc (origin/branchname) Remove dummy file 
   * 730c2ab Add dummy file # But `git show 730c2ab` includes the diffs between b89af06 and 93920f9 as well 
   | * 93920f9 (HEAD) Uninteresting commit 
   | * 91c7163 Uninteresting commit 
   | * ce51022 Commit with the changed commit message 
   |/ 
   * b89af06 Uninteresting commit 
   

   Lưu ý rằng, trừ HEAD, hiện nay là gì trỏ đến một số các cam kết về chi nhánh này.

Tôi nhanh chóng đi đến kết luận rằng ít nhất một số hành vi này chỉ đơn giản là lỗi trong git svn. Chắc chắn những gì tôi đã thấy ở điểm 4 ở trên không phải là điều gì đó sẽ xảy ra chút nào, ít nhất là bởi sự hiểu biết của tôi.

Answer 1

git svn reset thực sự là cách phù hợp để thực hiện. Giả sử SVN sửa đổi 4711 đã được thay đổi, các bước như sau:

1) Bỏ việc sửa đổi SVN thay đổi (và mọi thứ sau nó):

$ git svn reset -p 4711 
r1 = 18614es3df44c30da07 (refs/remotes/git-svn) 

2) Fetch sửa đổi đã thay đổi:

$ git svn fetch 
rereading 18614es3df44c30da07 
     A  trunk/a 
r4711 = 8dfb7d0758dbbc1d06004 (refs/remotes/git-svn) 
     A  trunk/b 
r4712 = e7337af3743e48c90ef3fa09906378b95997314c (refs/remotes/git-svn) 
[...] 

3) Bây giờ dữ liệu của git-svn được sửa chữa. Bạn vẫn phải sửa chữa các chi nhánh địa phương của bạn. Ví dụ, nếu chủ theo dõi thân cây SVN, chạy:

git rebase remotes/git-svn 

(nơi "điều khiển từ xa/git-svn" là chi nhánh từ xa theo dõi tạo ra bởi git svn - nó có thể có một cái tên khác nhau).

Điều này được giải thích khá rõ trong git svn manpage, trong phần trên tiểu mục "đặt lại".

Answer 2

git svn reset <revision-number> hoạt động, nhưng bạn phải chỉ định số sửa đổi sớm hơn cam kết vi phạm và sau đó làm lại git svn fetch. Giả sử cam kết đã thay đổi là R.100, bạn sẽ cần phải git svn reset 99 rồi thực hiện git svn fetch, chỉ điều đó sẽ tìm nạp lại cam kết đã thay đổi mới.

Tính đến trường hợp của bạn có chứa 730c2ab đè bẹp của b89af06-93920f9:

* 7b12bbc (origin/branchname) Remove dummy file 
* 730c2ab Add dummy file # But `git show 730c2ab` includes the diffs 
    between b89af06 and 93920f9 as well 
| * 93920f9 (HEAD) Uninteresting commit 
| * 91c7163 Uninteresting commit 
| * ce51022 Commit with the changed commit message 
|/ 
* b89af06 Uninteresting commit 

git-svn thỉnh thoảng làm điều đó trên các cam kết đó đã thay đổi. Tôi không chắc chắn về các chi tiết cụ thể, nhưng thỉnh thoảng tôi gặp phải khi bản sao làm việc của một cam kết cụ thể trên svn đã thay đổi kể từ lần tìm nạp cuối cùng, git svn sẽ thay đổi cùng với cam kết tiếp theo trong lần tìm nạp tiếp theo. Để giải quyết vấn đề này, bạn có thể thiết lập lại để trước cam kết, và tái nạp lại

EDIT:

Tôi không để ý trước đó ce51022 đã được tách ra từ chi nhánh chính của bạn. SVN phân nhánh khác và git-svn sẽ không thể tồn tại các nhánh git của bạn trên svn. Điều này cũng sẽ dẫn đến bị đè nén khi bạn thực hiện git svn dcommit hoặc git svn fetch/rebase