Mercurial Repository와 Git 상호 운용성

Mac에서 GIT을 사용합니다. 충분했다. 도구가 있고 경험이 있습니다. 그리고 나는 그것을 계속 사용하고 싶습니다. 여기에 전쟁이 없습니다 ...

문제는 항상 상호 운용성입니다. 대부분의 사람들은 SVN을 사용합니다. Git SVN은 기본적으로 작동하며 주름없는 솔루션입니다. 사람들은 계속해서 행복하게 SVN을 사용할 수 있으며 워크 플로와 도구를 잃지 않습니다.

자 ... 일부 사람들은 Mercurial과 함께옵니다. 그들에게 좋습니다 : 그들은 이유가 있습니다. 그러나 즉시 사용할 수있는 GIT HG를 찾을 수 없습니다. HG로 전환하고 싶지 않지만 여전히 저장소와 상호 운용해야합니다.

당신들 중 누구라도 이것에 대한 간단한 해결책을 알고 있습니까?

2012 년 6 월 업데이트. 현재 개발자가 git 쪽에서 작업하려고 할 때 Git / Hg 상호 운용성을위한 다음과 같은 방법이 있습니다.

1. Mercurial 및 hg-git 확장을 설치하십시오 . 패키지 관리자를 사용하거나을 사용하여 후자를 수행 할 수 있습니다 easy_install hg-git. 그런 다음 ~ / .hgrc에 다음이 있는지 확인하십시오.

   [extensions]
   hggit = 
   

   bookmarks여기 에서 확장명을 지정하는 것에 대한 언급이 있지만 v 1.8 이후 Mercurial에 내장되어 있습니다. 다음은 Windows에서 hg-git 설치에 대한 팁 입니다.

   hg-git이 있으면 위에 게시 된 Abderrahim Kitouni 와 같은 명령을 사용할 수 있습니다 . 이 방법은 2009 년 이후 개선되고 조정 되었으며 친숙한 래퍼 ( git-hg-again)가 있습니다. 최상위 디렉토리를 Mercurial과 Git의 작업 디렉토리로 동시에 사용합니다. defaultMercurial 저장소 의 (이름이없는) 브랜치 끝과 동기화 된 Mercurial 책갈피를 작성하고 해당 책갈피에서 로컬 Git 브랜치를 업데이트합니다.

2. git-remote-hg 는 Mercurialhg-git확장을기반으로하는 다른 래퍼입니다. 이것은 또한git-remote-helpers프로토콜 (따라서 그 이름)을 사용합니다. Git 작업 디렉토리에 대해서만 최상위 디렉토리를 사용합니다. Mercurial 저장소를 노출시키지 않습니다. 또한 Git과 Mercurial 간의 동기화를보다 안전하고 관용적으로 gitlike로 만들기 위해 두 번째 베어 Git 저장소를 유지 관리합니다.

3. 자식-HG의 스크립트 (이전의 유지 여기가 )에 따라 다른 방법을 사용 hg-fast-export로부터 빠른 속도로 수출 프로젝트를 . 방법 2와 마찬가지로 베어 Mercurial 저장소와 추가 베어 Git 저장소도 유지합니다.

   당기기 위해이 도구는 Mercurial 책갈피를 무시하고 대신 이름이 지정된 모든 Mercurial 분기를 Git 분기로 가져오고 기본 (이름이없는) Mercurial 분기를 마스터로 가져옵니다.

   일부 해설> 자식뿐 아니라 그것이 내가 설명해 년 12 2011 년 7 git-> HG 푸시 지원 합병했다고 주장 hg- 인 것으로이 도구에 대해 설명 이러한 도구의 검토 , 방법,하지만이 도구의 시도가 구현을 푸시 지원이 작동하지 않는 것 같습니다.

4. git-remote-hg라는 다른 프로젝트 도 있습니다 . 위에 나열된 버전과 달리이 버전은 hg-git에 의존하지 않고 Mercurial Python API에 직접 액세스합니다. 현재이를 사용하려면 패치 버전의 git이 필요합니다. 아직 시도하지 않았습니다.

5. 마지막으로 Tailor 는 다양한 VCS간에 점진적으로 변환하는 프로젝트입니다. 이것의 개발이 적극적으로 진행되지 않을 것 같습니다.

이러한 접근법 중 처음 세 가지 방법은 조사를 설득하기에 충분히 가벼워 보였다. 설정에서 실행할 수 있도록 몇 가지 방법으로 조정해야했고, 개선하기 위해 더 조정하는 방법을 보았습니다. 그런 다음 평가를 위해 서로 더 행동하도록 더 조정했습니다. 더 효과적으로. 그런 다음 다른 사람들도 동일한 평가를 수행하기 위해 이러한 조정을 원한다고 생각했습니다. 따라서 처음 세 가지 도구 중 하나를 내 버전으로 설치할 수 있는 소스 패키지 를 만들었습니다 . 또한 필요한 hg-fast-export부품 을 설치해야 합니다. ( hg-git자체적 으로 설치해야합니다 .)

나는 당신이 그들을 시도하고 가장 잘 작동하는 것을 스스로 결정하도록 권장합니다. 이 도구가 깨지는 경우에 대해 기뻐할 것입니다. 나는 그것들을 업스트림 변경 사항과 동기화하고 업스트림 작성자가 내가 생각하는 유용한 조정을 인식하도록 노력할 것입니다.

위에서 언급했듯이 이러한 도구를 평가할 때 git-hg푸시가 아닌 Mercurial에서 가져 오기에만 사용할 수 있다는 결론에 도달했습니다 .

이와 관련하여 Git과 Mercurial 간의 유용한 비교 / 번역 매뉴얼은 다음과 같습니다. 일부 경우 이미 Git을 알고있는 사용자를 대상으로합니다.

• Git 사용자를위한 Mercurial
• 힘내와 머큐리얼-비교 및 대조
• Mercurial과 Git의 차이점은 무엇입니까
• Mercurial and Git : 기술적 비교
• 힘내 HG 로제타 스톤
• 사제 코딩 : 머큐리얼
• Francisoud의 블로그 : Git vs Mercurial (HG)
• 힘내 vs Mercurial

기본 지원을 제공하는 새로운 git-remote-hg가 있습니다.

Mercurial 및 Bazaar를위한 Git의 브릿지 지원

git-remote-hg 를 $ PATH에 복사 하고 실행 가능하게 만드십시오. 그러면 종속성이 없습니다 (Mercurial 제외).

git clone hg::https://www.mercurial-scm.org/repo/hg/

마치 기본 Git 리포지토리 인 것처럼 밀어 넣을 수 있습니다.

새로운 Git 브랜치를 누르면 Mercurial 북마크가 생성됩니다.

자세한 정보는 git-remote-hg 위키 를 참조하십시오.

hg-git 을 사용할 수 있어야합니다 .

hg clone <hg repository>

편집 ~/.hgrc및 추가 :

[extensions]
hgext.bookmarks =
hggit =

북마크를 만들면 mastergit 안에 있습니다 :

cd <repository>
hg bookmark -r default master

.hg/hgrc저장소에서 편집 하고 추가하십시오.

[git]
intree = true

이제 git 저장소를 만들 수 있습니다 :

hg gexport

결과 디렉토리를 git clone으로 사용할 수 있습니다. 수은에서 당기는 것은 다음과 같습니다.

hg pull
hg gexport

그리고 수은으로 밀기 :

hg gimport
hg push

(예,이 워크 플로에서 hg를 사용해야하지만 해킹은 모두 git에 있습니다)

추신이 워크 플로에 문제가 있으면 버그를 신고하십시오.

http://repo.or.cz/w/fast-export.githg2git 에서 찾을 수있는 python 스크립트이며 빠른 내보내기의 일부인을 사용해보십시오 .

그래도 수은이 설치되어 있어야합니다.

HG-자식이 때문에 두 웨이 브리지, 그것은 또한 당신이 의욕에 힘내에서 변경 집합을 밀어 수 있습니다.

수은 - 힘내 의욕 플러그인 . 직접 시도하지는 않았지만 체크 아웃 할 가치가 있습니다.

https://github.com/cosmin/git-hggit-hg 에서 큰 성공을 거두었습니다 (작업 설치도 필요합니다 ). 가져 오기, 당기기 및 푸시를 지원하며 (유사한 기능에서 git까지) 보다 안정적입니다 .hghg-githg

사용 예는 https://github.com/cosmin/git-hg#usage 를 참조 하십시오 . 사용자 인터페이스는와 매우 유사합니다 git-svn.

git-hg복제 된 각 hg 저장소에 추가 디스크 공간 이 필요합니다. 구현에는 전체 수은 클론, 추가 git bare 클론 및 실제 git repo가 ​​사용됩니다. 필요한 디스크 공간은 일반적인 자식 전용 사용량의 약 3 배입니다. 추가 사본은 .git작업 디렉토리 의 디렉토리 아래 (또는 GIT_DIR평소와 같이 가리키는 위치 )에 저장됩니다.

주의 사항 : 것을 기본적인 문제 git-hg1 매핑 사이 : 시도를 해결하기 위해 어떤 일이 없다는 것이다 git및 hg기능을 제공합니다. 가장 큰 문제는 자식 지점 사이의 임피던스 부정합이다 HG 이름이 나뭇 가지 와 HG라는 이름의 지점 과 HG 북마크 (그보기의 모든 지점과 같은 많은 git사용자). 관련된 문제는 hg기본적으로 지점 커밋 메시지 만 템플릿 커밋 메시지에 추가되는 git과는 달리 버전 기록에 원래 이름의 분기 이름을 저장하려고 시도한다는 것입니다.

주장 사이의 상호 운용 다리를 만들 수 있음을 모든 도구 git와 hg가이 임피던스 매칭을 다루는 것 방법을 설명한다. 그런 다음 선택한 솔루션이 필요에 맞는지 결정할 수 있습니다.

사용하는 솔루션 git-hg은 모든 hg 책갈피를 버리고 명명 된 분기를 자식 분기로 변환하는 것입니다. 또한 git master 브랜치를 기본 이름이없는 hg 브랜치로 설정합니다.

hggit을 시도했습니다. 나는 git'ers와 hg'ers의 작업에 대처해야하기 때문에 나를 위해 일합니다. 특히 리뷰의 경우 이것은 좋습니다.

해당 주제에 대한 사소한 문제 / 경고 :

hg를 사용하여 안정적인 Linux 커널 저장소를 복제하려고했습니다. 이 리포지토리는 git으로 유지 관리되며 일반적으로 많은 수의 파일이 있습니다.

매우 느렸다. 작업 사본 을 완전히 복제 하고 업데이트하는 데 2 일이 걸렸습니다 .

나는 mutt의 hg repo 에서 cosmin의 git-hg 와 abourget의 git-hg-again을 모두 시도했지만 나중에 병합 순서를 잘 존중하는 것 같습니다. 아래 스크린 샷에서 볼 수 있습니다.

cosmin의 git-hg가 가져온 mutt의 병합 히스토리 그래프 :

abourget의 git-hg-again이 가져온 mutt의 병합 히스토리 그래프 :

mutt의 hg 저장소에 hgk로 표시 한 실제 히스토리 그래프 :

위에서 볼 수 있듯이 abourget의 git-hg-again에 의한 두 번째 그래프 는 원래 hgk 그래프와 매우 가깝고 실제로 mutt의 실제 워크 플로우를 반영합니다.

내가 찾은 git-hg-again의 한 가지 단점은 'hg'원격을 추가하지 않고 모든 참조를 로컬 태그로 가져 오는 것입니다 .git-hg는 멋진 'hg'원격이 업스트림 hg 저장소를 나타냅니다.

Git-hg Mirror 서비스를 통해 양방향 hg-git (및 git-git, hg-hg) 동기화도 가능합니다 . 그것은 배후에서 hg-git (다른 것들 중에서)을 사용하며 코드는 오픈 소스입니다.

면책 조항 : 나는 그 뒤에 회사에서 왔어요.