version-control hg教學 - Git與Mercurial Repository的互操作性




scm download (9)

你應該可以使用hg-git

hg clone <hg repository>

編輯~/.hgrc並添加:

[extensions]
hgext.bookmarks =
hggit =

創建一個書籤,以便在git中擁有一個master

cd <repository>
hg bookmark -r default master

編輯存儲庫中的.hg/hgrc並添加:

[git]
intree = true

現在你可以創建git倉庫了:

hg gexport

你可以使用生成的目錄作為git克隆。 從mercurial拉動將是:

hg pull
hg gexport

並推動mercurial:

hg gimport
hg push

(是的,你需要在這個工作流程中使用hg,但是你的黑客將全部在git中)

PS如果您在此工作流程中遇到問題,請提交錯誤。

我在Mac上使用GIT。 說夠了。 我有工具,我有經驗。 我想繼續使用它。 這裡沒有戰爭...

問題總是與互操作性有關。 大多數人使用SVN,這對我很好。 Git SVN開箱即用,並且是一個沒有裝飾的解決方案。 人們可以繼續高興地使用SVN,我不會失去我的工作流程,也不會失去我的工具。

現在......有些人與Mercurial一起出現。 對他們很好:他們有他們的理由。 但我找不到任何GIT HG。 我不想切換到HG,但我仍然需要與其存儲庫進行互操作。

你們中的任何人都知道這個簡單的解決方案?


有一個新的git-remote-hg提供本地支持:

Meritial和Bazaar在Git中的橋樑支持

只需將git-remote-hg複製到您的$ PATH,使其可執行,就是這樣,沒有任何依賴關係(Mercurial除外):

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

你應該能夠像從本地的Git倉庫那樣推拉它。

當你推新的Git分支時,Mercurial書籤將為他們創建。

有關更多信息,請參閱git-remote-hg wiki


我已經嘗試了git-hggit-hg-againmutt的hg repo進行了嘗試,似乎後者尊重合併的順序,前者有點隨機。 你可以從下面的截圖中看到。

git-hg導入的mutt合併歷史圖:

git-hg-again通過git-hg-again導入的mutt合併歷史記錄圖:

由hgk在mutt的hg倉庫中繪製的實際歷史圖:

從上面可以看到, git-hg-again的第二張圖與原始的hgk圖非常接近,實際上反映了mutt的真實工作流程。

我發現git-hg的一個缺點是它沒有添加'hg'remote,而是將所有的ref作為本地標籤導入,git-hg有一個很棒的'hg'remote代表上游的hg repo。


我從git-hg獲得git-hg巨大成功(也需要安裝hg )。 它支持取,拉和 ,對於我來說比hg-git (從hg到git的類似功能)更穩定。

有關使用示例,請參閱https://github.com/cosmin/git-hg#usage 。 用戶界面非常類似於git-svn

git-hg需要額外的磁盤空間用於每個克隆的hg回購。 該實現使用完整的mercurial clone,一個額外的git bare clone和實際的git repo。 所需的磁盤空間大約是正常git only用法的3倍。 額外的副本存儲在工作目錄的.git目錄下(或像往常一樣由GIT_DIR指向的位置)。

注意: git-hg試圖解決的基本問題是githg之間不存在1:1映射。 最大的問題是git分支和hg未命名分支hg命名分支hg書籤之間的阻抗不匹配(所有這些看起來很像分支給git用戶)。 一個相關的問題是, hg試圖保存版本歷史中的原始命名分支名稱,而不是git,默認情況下分支名稱只添加到模板提交消息中。

任何聲稱在githg之間建立可互操作橋樑的工具都應該解釋它將如何處理這種阻抗匹配。 然後,您可以決定所選解決方案是否適合您的需求。

git-hg使用的解決方案是放棄所有的hg書籤並將命名分支轉換為git分支。 另外,它將git master分支設置為默認的未命名hg分支。



從2012年6月開始更新。目前,當開發人員希望從git方面開始工作時,似乎有以下Git / Hg互操作性方法:

  1. 安裝Mercurial和hg-git擴展 。 您可以使用軟件包管理器或使用easy_install hg-git來完成後者。 然後確保以下內容在你的〜/ .hgrc中:

    [extensions]
    hggit = 
    

    您可能會在這裡看到一些關於指定bookmarks擴展名的引用,但自1.8版以來,它已內置到Mercurial中。 這裡有一些關於在Windows上安裝hg-git的提示

    一旦你有了hg-git,你可以使用上面提到的Abderrahim Kitouni的命令。 這種方法自2009年以來已經完善和調整 ,並且有一個友好的包裝: git-hg-again 。 這將同時使用頂級目錄作為Mercurial和Git的工作目錄。 它創建一個Mercurial書籤,它與Mercurial存儲庫中的default (未命名)分支的提示保持同步,並從該書籤更新本地Git分支。

  2. git-remote-hg是一個不同的包裝器,也基於Mercurial hg-git擴展。 這另外使用了git-remote-helpers協議(因此它的名字)。 它僅將頂級目錄用於Git工作目錄; 它保持其Mercurial存儲庫裸露。 它還維護第二個裸Git倉庫,使Git和Mercurial之間更安全,更習慣地使用gitlike。

  3. git-hg腳本(以前here維護)使用不同的方法,基於快速導出項目中的 hg-fast-export 。 像方法2一樣,這也會保留一個純粹的Mercurial存儲庫和一個額外的裸露Git存儲庫。

    對於拉取,此工具忽略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只能用於從Mercurial中提取,而不能用於推送。

相關的,下面是Git和Mercurial之間的一些有用的比較/翻譯手冊,在某些情況下針對已經了解Git的用戶:


這是一個古老的問題,但我認為值得一提:git -hg鏡像服務也可以使用雙向hg-git(和git-git,hg-hg)同步。 它在幕後使用hg-git(其他),其代碼也是開源的。

免責聲明:我來自背後的公司。



為了完全清除編碼器目錄中的一些意外更改,我們使用了:

git add -A .
git reset --hard HEAD

只是git reset --hard HEAD將擺脫修改,但它不會擺脫“新”文件。 在他們的情況下,他們意外地隨機拖動了一個重要的文件夾,所有這些文件被Git視為新文件,所以reset --hard沒有修復它。 通過運行git add -A . 事先,它使用git顯式跟踪它們,以便通過重置來消除它們。





git version-control mercurial interop dvcs