Mercurial Repository와의 Git 상호 운용성

Mercurial Repository와의 Git 상호 운용성

저는 맥에서 GIT를 사용합니다.그 정도면 충분해.도구도 있고, 경험도 있습니다.그리고 저는 그것을 계속 사용하고 싶습니다.여긴 전쟁이...

문제는 항상 상호 운용성에 있습니다.대부분의 사람들이 SVN을 사용하는데, 이것은 저에게 좋습니다.Git SVN은 즉시 사용할 수 있는 솔루션입니다.사람들은 SVN을 계속해서 즐겁게 사용할 수 있으며 저는 워크플로우와 툴을 잃지 않습니다.

머큐리얼과 함께 온 사람들이 있습니다그들에게는 좋습니다. 그들에게는 이유가 있습니다.하지만 GITHG를 바로 찾을 수 없습니다.저는 HG로 전환하고 싶지 않지만, 여전히 그들의 저장소와 상호 운용해야 합니다.

이에 대한 간단한 해결책을 아시는 분 있나요?

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

머큐리얼과 바자를 위한 깃의 다리 지원.

git-remote-hg만 복사하면 됩니다.$PATH실행 파일로 만들고, 이것으로 끝입니다. 종속성이 없습니다(Mercurial 제외).

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

당신은 그것이 네이티브 Git 저장소인 것처럼 밀고 당길 수 있어야 합니다.

새 Git 분기를 누르면 해당 분기에 대한 Mercurial 북마크가 생성됩니다.

자세한 내용은 git-remote-hg Wiki를 참조하십시오.

당신은 hg-git를 사용할 수 있어야 합니다.

hg clone <hg repository>

편집을~/.hgrc합니다.

[extensions]
hgext.bookmarks =
hggit =

북마크를 만들 수 .masteringit:

cd <repository>
hg bookmark -r default master

편집을.hg/hgrc에 추가합니다

[git]
intree = true

이제 Git 저장소를 만들 수 있습니다.

hg gexport

생성된 디렉터리를 깃 클론으로 사용할 수 있습니다.수은에서 추출하는 것은 다음과 같습니다.

hg pull
hg gexport

수은주로 밀어넣기:

hg gimport
hg push

(예, 당신은 이 워크플로우에서 hg를 사용해야 하지만 당신의 해킹은 전부가 될 것입니다.)

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

2012년 6월부터 업데이트.현재 개발자가 Git 측에서 작업하기를 원할 때 Git/Hg 상호 운용성을 위한 다음과 같은 방법이 있는 것으로 보입니다.

1. Mercurial 및 hg-git 확장을 설치합니다.패키지 관리자를 사용하여 후자를 수행할 수 있습니다.easy_install hg-git 다음 에 합니다.

   [extensions]
   hggit = 
   

다음을 지정하는 것에 대해 설명하는 몇 가지 참조를 볼 수 있습니다.bookmarks여기서도 확장이 가능하지만 v1.8부터 Mercurial에 내장되어 있습니다.다음은 Windows에 hg-git를 설치하는 방법에 대한 몇 가지 팁입니다.

일단 hg-git을 갖게 되면, 위에 게시된 Abderrahim Kituni와 같은 명령어를 대략적으로 사용할 수 있습니다.하지만 이 방법은 2009년부터 개선되고 조정되었으며 친근한 포장지가 있습니다: git-hg-again.이렇게 하면 Mercurial 및 Git의 작업 디렉토리로 동시에 최상위 디렉토리가 사용됩니다.Mercurial 북마크를 생성하여 팁과 동기화합니다.defaultMercurial 저장소의 (이름 없음) 분기 및 해당 책갈피에서 로컬 Git 분기를 업데이트합니다.

2. git-remote-hg는 머큐리얼을 기반으로 하는 다른 래퍼입니다.hg-git연장의이는 추가적으로 다음을 활용할 수 있습니다.git-remote-helpers프로토콜(이름 포함).Git 작업 디렉터리에 대해서만 최상위 디렉터리를 사용하며 Mercurial 저장소를 그대로 유지합니다.또한 Git와 Mercurial 간의 동기화를 더 안전하고 관용적으로 git와 유사하게 만들기 위해 두 번째 베어 Git 저장소를 유지합니다.

3. git-hg 스크립트(이전에는 여기서 유지됨)는 다음과 같은 다른 방법을 사용합니다.hg-fast-export고속 수출 프로젝트에서.방법 2와 마찬가지로, 이것은 또한 베어 머큐리얼 저장소와 추가 베어 깃 저장소를 유지합니다.

풀링의 경우 이 도구는 Mercurial 북마크를 무시하고 대신 명명된 모든 Mercurial 분기를 Git 분기로 가져오고 기본(이름 없음) Mercurial 분기를 마스터로 가져옵니다.

일부 주석에서는 이 도구가 hg->git 전용이라고 설명하지만, 2011년 12월 7일에 git->hg 푸시 지원을 통합했다고 주장합니다.그러나 이러한 툴에 대한 리뷰에서 설명했듯이 푸시 지원을 구현하려는 이 툴의 방식은 실행 가능하지 않은 것 같습니다.

4. git-remote-hg라는 다른 프로젝트도 있습니다.위에 나열된 버전과 달리 이 버전은 hg-git에 의존하지 않고 Mercurial Python API에 직접 액세스합니다.현재로서는 그것을 사용하기 위해서는 git의 패치된 버전도 필요합니다.아직 안 먹어봤어요.

5. 마지막으로 Tailor는 다양한 VCS 간에 점진적으로 변환하는 프로젝트입니다.이것의 개발은 공격적으로 계속되지 않을 것으로 보입니다.

이 접근법 중 처음 세 가지는 제가 조사하도록 설득하기에 충분히 가벼워 보였습니다.설정에서 실행되도록 하기 위해 몇 가지 방법으로 수정해야 했고, 개선하기 위해 추가로 수정할 수 있는 몇 가지 방법을 보았습니다. 그리고 나서 더 효과적으로 평가할 수 있도록 서로 더 비슷하게 동작하도록 수정했습니다.그러면 다른 사람들도 같은 평가를 하기 위해 이러한 조정을 좋아할 것이라고 생각했습니다.그래서 처음 세 가지 도구 중 하나를 설치할 수 있는 소스 패키지를 만들었습니다.또한 필요한 설치도 처리해야 합니다.hg-fast-export(설치하셔야 .)hg-git혼자 힘으로.)

저는 여러분이 그것들을 시험해 보고 어떤 것이 가장 효과적인지 스스로 결정하기를 권장합니다.이 도구들이 고장나는 경우에 대해 듣게 되어 기쁩니다.업스트림 변경사항과 동기화되도록 하고 업스트림 작성자가 유용하다고 생각하는 수정사항을 인지하도록 노력하겠습니다.

위에서 언급했듯이, 이 도구들을 평가하면서, 저는 다음과 같은 결론에 도달했습니다.git-hg머큐리얼에서 끌어내는 데만 사용할 수 있고 밀 때는 사용할 수 없습니다.

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

• Git 사용자를 위한 머큐리얼
• 깃과 수은 - 비교 및 대조
• 머큐리얼과 깃의 차이점은 무엇입니까?
• 머큐리얼과 깃: 기술적 비교
• 깃그로세타 스톤
• 홈브루 코딩:머큐리얼
• 프란치스코의 블로그: 깃 대 머큐리얼 (hg)
• 깃 대 머큐리얼

시도해 보세요hg2git이것은 파이썬 스크립트이며 빠른 내보내기의 일부이며 http://repo.or.cz/w/fast-export.git 에서 찾을 수 있습니다.

수은을 설치해야 합니다.

hg-git는 양방향 브리지이기 때문에 Git에서 Mercurial로 변경 세트를 푸시할 수도 있습니다.

HG-Git 머큐리얼 플러그인.제가 직접 해보지는 않았지만, 확인해 볼 만한 가치가 있을지도 모릅니다.

로 큰 성공을 거두었습니다.git-hghttps://github.com/cosmin/git-hg 에서 (작업 중인 설치 필요)hgfetch, pull 및 밀다 그리고 나에게는 더 안정적입니다.hg-git (의한 기능)hggit).

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

그git-hg복제된 각 hgrepo에 대해 추가 디스크 공간이 필요합니다.이 구현에서는 전체 수은 복제본, 여분의 Git 베어 복제본 및 실제 Git repo를 사용합니다.필요한 Disk 공간은 일반 Git 전용 사용량의 약 3배입니다.은 추가복아저다니장 됩니다..git작업 디렉토리(또는 위치)의 디렉토리GIT_DIR여느 때와 같이)

주의: 기본적인 문제는git-hg해결하려고 노력하는 것은 사이에 1:1 매핑이 없다는 것입니다.git그리고.hg특징들.가장 큰 문제는 git 브랜치와 hg 명명되지 않은 브랜치, hg 명명된 브랜치와 hg 북마크 사이의 임피던스 불일치입니다(모든 것이 브랜치와 매우 유사합니다).git와 는 이와 관련된 문제입니다.hg에서는 기본적으로 분기 이름이 템플릿 커밋 메시지에만 추가되는 git와 달리 원래 이름이 지정된 분기 이름을 버전 기록에 저장하려고 합니다.

와 사이에 상호 운용 가능한 브리지를 만들겠다고 주장하는 모든 도구는 이 임피던스 일치를 어떻게 처리할지 설명해야 합니다.그런 다음 선택한 솔루션이 필요에 적합한지 여부를 결정할 수 있습니다.

git-hguses는 모든 hg 책갈피를 삭제하고 명명된 분기를 git 분기로 변환합니다.또한 git master 브랜치를 기본 이름 없는 hg 브랜치로 설정합니다.

hggit 해봤어요.저한테는 효과가 있어요, 왜냐하면 저는 기생들과 기생들의 일을 처리해야 하기 때문입니다.특히 리뷰의 경우 이것은 훌륭합니다.

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

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

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

mutt의 hgrepo에서 cosmin's git-hg와 borge's git-hg를 모두 다시 시도해봤는데, 후자가 병합 순서를 잘 존중하는 것 같고, 전자는 약간 무작위인 것 같습니다.아래 스크린샷을 보시면 알 수 있습니다.

cosmin의 git-hg에 의해 가져온 mutt의 병합 기록 그래프:

bugg의 git-hg-again에서 가져온 mutt의 병합 기록 그래프:

mutt의 hg 저장소에 hgk로 표시된 실제 이력 그래프:

위에서 볼 수 있듯이, 버짓의 git-hg-again에 의한 두 번째 그래프는 원래 hgk 그래프에 매우 가깝고 실제로 뮤트의 실제 워크플로우를 반영하고 있습니다.

git-hg-again의 한 가지 단점은 'hg' 리모컨을 추가하지 않고 모든 참조를 로컬 태그로 가져온다는 것입니다. git-hg 리모컨은 업스트림 hg repo를 나타냅니다.

양방향 hg-git(및 git-git, hg-hg) 동기화는 Git-hg Mirror 서비스로도 가능합니다.그것은 배경 뒤에서 (다른 것들 중에서) hg-git을 사용하고 그것의 코드 또한 오픈 소스입니다.

---

고지 사항:저는 그 뒤에 있는 회사에서 왔습니다.

2021년 최신 답변은 파이어폭스 등에서 사용되는 것으로 보입니다.

이 페이지에서 제안하는 다른 스크립트는 유지 관리되지 않거나 오래된 소프트웨어(일반적으로 python 2.7)를 실행해야 합니다.반대로, cinnabar는 python 3.5+와 함께 작동하며 적어도 작성 날짜까지 유지됩니다.

설치되면 cinnabar로 접두사를 복제할 수 .hg:::

git clone hg::https://hg.mozilla.org/mozilla-unified

또는 원격을 추가하거나 다음으로 설정합니다.

git remote set-url origin hg::https://hg.mozilla.org/mozilla-unified
git fetch origin

수은 리모콘으로 이동할 수 있습니다.

용사를 합니다.hg2git그리고.git2hg명령을 사용하면 git commit sha1s를 수은 변경 집합으로 변환하고 다시 변환할 수 있습니다.github 페이지에서 더 많은 문서를 사용할 수 있습니다.

언급URL : https://stackoverflow.com/questions/883452/git-interoperability-with-a-mercurial-repository