2015-01-15 10 views
5

git-svn을 사용하여 공유 Subversion 저장소의 복제본을 보관합니다. 최근에 다른 사용자가 수정본 (a lathis SO question)의 커밋 메시지를 편집 한 후 해당 수정본을 git svn fetch에 보냈습니다. 어떻게하면 Git 클론이 올바른 커밋 메시지를 갖도록 수정할 수 있습니까?이전 Subversion 개정판을 수정 한 후 git-svn 저장소를 수정했습니다.

나는 git svn reset 다음에 git svn fetch 다음에이 커밋을 다시 업데이트하고 내 로컬 브랜치를 수정해야하지만 실제로는 아무 것도 수행하지 않는 것으로 업데이트해야합니다. git svn fetch은 재설정 된 커밋을 다시 페치하지 않습니다.

(예 나는이 메시지는 나쁜 생각이었다 커밋 변경 생각하지만 내가 제어를 통해이 일이 아니다.)

업데이트 : 나는 사실, 내가 시도했던 (제안 sleske 과정을 시도 그것은 질문을하기 전에 그것을 시도하지만, 나는 단지 다시 시도했다.) 운이 없다.

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

[email protected] ~/code ((358a2dd...)) Fri 16 Jan 15:33:06 
$ git svn fetch 

[email protected] ~/code ((358a2dd...)) Fri 16 Jan 15:33:08 
$ 

git svn fetch로부터 출력 없습니다 (또는 거기 내가 마지막으로 실행 한 이후 저지른 경우가 있지만, 그것은 단지 오래된 것들을 refetching하지, 새로운 커밋을 가져 오는 것), 그리고 : 나는 출력 아래와 같이 얻을 sleske의 예와 같이 특별히 rereading 메시지가 없습니다.

관련성이있는 경우 Git v2.0.4를 사용하고 있습니다.

업데이트 2는 : 약간 아래 .git/config을 편집 됨 :

[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/* 

거기의 많은,하지만 정말 흥미로운 얻을 곳이기 때문에 내가 git branch -avv의 최대 출력을 게시 할 수 있습니다, 그래서 ' 내가 한 모든 것의 목록을 게시 할 것입니다 :

  1. 오류가있는 지점 이외의 다른 지점에 대한 점검이있었습니다. git svn reset을 실행하면 아무런 차이가 없습니다. remotes/origin/branchname은 더 최근의 커밋을 계속 가리 킵니다. 놀랍지 만 git svn fetch은 아무 것도하지 않았습니다.

  2. remotes/origin/branchname을 확인하고 git svn reset을 다시 실행했습니다. 이것은 효과가있었습니다 : remotes/origin/branchname은 더프 커밋의 부모를 가리켰습니다.

  3. 나는 git svn fetch을 실행했습니다. 이것은 절대적으로 아무것도하지 않았다 : 어떤 커밋도 가져 오지 않았고 remotes/origin/branchname은 움직이지 않았다.

  4. Subversion 저장소 (하나는 빈 파일을 추가하고 다음은 다시 삭제함)의 해당 분기에 더미 커밋을 작성한 다음 git svn fetch again을 실행했습니다.

    정말 이상한 부분이 있습니다. 더프 커밋을 다시 가져 오지 않았습니다. 대신 더미 파일을 추가 한 커밋에서 가져 오기가 시작되어 프로세스에서 "인덱스 불일치"가보고되었습니다. 더미 파일을 추가 한 커밋에서 git show을 실행하면 내가 다시 커밋 한 파일과 더미 파일 사이의 모든 차이점이 표시됩니다 범하다.

    지금, git log --graph --decorate --pretty=oneline --abbrev-commit HEAD origin/branchname 실행하는 다음과 같습니다

    * 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 
    

    HEAD 이외의 것으로,이 지점에 커밋의 일부를 가리키는 아무것도 지금은 없다.

이 동작 중 적어도 일부는 단순히 git svn의 버그 일뿐입니다. 위의 4 번에서 보았던 것이 적어도 내 이해에 의해 전혀 일어나지 않는 것이 분명합니다.

+0

게시 할 수 있습니까 : ".git/config"(git-svn remote가 구성되어있는 곳)의 내용 및 b)'git svn reset ... '호출 전과 후에'git branch -avv'의 출력. 후자는'git svn'이 사용하는 원격 추적 브랜치에 어떤 일이 일어나는지 보여 주어야합니다. – sleske

+0

@sleske 요청한대로'.git/config'를 추가했고,'git branch -avv'의 결과를 기반으로 조금 파고 들었습니다. 그것은 매우 이상합니다. –

+1

그래, 매우 이상하고'git svn'의 버그 일 가능성이 높습니다. 더 많은 도움을 얻으려면 재현 가능한 테스트 케이스를 제공해야합니다. 로컬 SVN 저장소를 만드는 스크립트를 작성한 후'git ​​svn'을 통해 체크 아웃 할 수 있습니다. 동일한 repo 레이아웃과 옵션을 사용하고 구조적으로 유사한 커밋을 만들면 문제를 재현 할 수 있습니다. – sleske

답변

1

git svn reset 실제로 올바른 방법입니다. SVN 개정판 (4711)가 변경된 가정하면, 단계는 다음과 같다

1)) 그 후 변경된 SVN 버전 (및 모든 폐기 :

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

:

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

2)는 변경된 버전을 반입 3) 이제 git-svn의 데이터가 복구됩니다. 여전히 지회를 수리해야합니다. 마스터가 SVN 트렁크를 추적 예를 들어, 실행

git rebase remotes/git-svn 

("리모트/자식 - svn을"은 git svn에 의해 생성 된 원격 추적 지점이 어디 - 그것은 다른 이름을 가질 수있다).

이 내용은 git svn manpage의 "reset"하위 명령 섹션에서 매우 잘 설명됩니다.

+0

이것은 원래 시도한 것이지만'git svn fetch'는'rereading' 단계를 수행하지 않습니다. 원본 질문을 전체 출력으로 업데이트했습니다. –

2

git svn reset <revision-number> 작동하지만 위의 커밋보다 이전 버전 번호를 지정하고 git svn fetch을 다시 수행해야합니다. 변경된 커밋이 R.100이라고 가정하면 git svn reset 99을 수행하고 git svn fetch을 수행하면 새로운 커밋 된 커밋 만 다시 페치됩니다. 730c2ab의 사건의로

b89af0693920f9의 숙청 함유 :

* 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 

자식-SVN 가끔 변경 커밋에 그렇게. 구체적인 내용은 확실하지 않지만 때때로 마지막 가져 오기 이후 svn에 대한 특정 커밋의 작업 복사본이 변경되었을 때 git svn이 다음 가져 오기에서 다음 커밋과 함께 변경 사항을 스쿼시합니다. 이 문제를 해결하기 위해, 당신은 커밋 이전으로 재설정 할 수 있으며, 다시

EDIT 다시 가져 오기 :

내가 ce51022 이미 주요 지점에서 분리되어 이전에 통보하지 않았다. SVN은 다른 방법으로 분기를 수행하고 git-svn은 svn에서 git 브랜치를 유지할 수 없습니다. 이것은 git svn dcommit이나 git svn fetch/rebase를 수행 할 때도 스쿼시 커밋이 발생합니다.