Transfer the githashes to the mercurial repository (locally)

[ouboub]

Hi I am a mercurial user, who clones git repository to my machine and then use, at the moment Felip's converter to generate the corresponding mercurial repositories (with named branches), work and would then to push to the remote git server via hg-git. That however currently is not possible since the converter does not transfer the git hashes to the (local) mercurial repository. Since your fork has very similar features and since it is not clear whether Felipe still is developping his code, is there any change that you might consider implementing such a feature? I don't know enough git and python to try this even. I will rise this question also on the hg-git mailing list regards Uwe Brauer

[mnauw]

I am not quite sure what it is that fails (as in, "not possible") and what is meant by "git hashes not in mercurial repository"? In particular, how would or could the latter be done? There may be various ways to store "additional metadata" (in Mercurial) but there is no such standardized way for external/git hashes (as far as I know). In any case, I am guessing (based on some testing) that when trying to do as you describe, then the push (by hg-git) comes up with new git commits (for the pre-existing git ones). Upon some investigation, that might be because hg-git sneaks in such (aforementioned) "extra metadata" into the git commit message (e.g. HG:rename-source hg), which leads to a different hash (etc). The above commit makes a minor adjustment in git-remote-hg that should dissuade hg-git from doing so when it pushes back to git (and therefore end up re-using the pre-existing ones).

However, the above matching back-and-forth round-trip likely only extends to "basic cases" (i.e. some simple history). There are likely (if not surely) differences in how both tools handle more complicated situations. As such, it is generally not advisable to mix 2 tools (especially without any standardized interoperable specification). It is also a bit puzzling as to why? As a mercurial user, it would seem that only using hg-git suffices?

By the way, as mentioned by hg-git README, there are yet other alternatives (such as a git extension) that may be (more) helpful?

[ouboub]

Hi

Thanks for your detailed answer, I run some tests and have a proposal to make

As I was pointed out be Felipe , hg-git creates its one file git-mapfile that connects git hashes to hg hashes.

I run some experiments I am describing below, and in a nutshell I would like to ask/suggest if the git-hg-remote converter could generate a git-mapfile (whose syntax I describe below) based on the files git-hg-remote already generated namely

marks-git and marks-hg

I don't posses enough python knowledge to even try to do this.

Notation

hg-git

A repository that will be generated, or cloned by hg-git will take the prefix hg-git

git-hg-remote

A repository that will be generated, or cloned by git-hg-remote will take the prefix git-hg-remote

A public very simple repository at gitlab

https://gitlab.com/kalthad/named-branch-only

Clone with git

check the git branches

git branch -a 
git log --all --oneline --decorate --graph --first-parent 

Start an empty local hg repository

hg init git-hg-remote-named-branch

configure git-hg-remote

Set up the mercurial remote

git remote add hg-remote hg::../git-hg-remote-named-branch-only
git config remote.hg-remote.push 'refs/heads/*:refs/heads/branches/*'
git config remote.hg-remote.pull 'refs/heads/*:refs/heads/branches/*'

Push only if switched to

git push hg-remote default
git push hg-remote feature
git push hg-remote remotes/origin/feature:refs/heads/branches/feature

Try to generate a git-mapfile based on marks-git marks-hg

orginal git-mapfile (when cloning with hg-git or generating and pushing with hg-git

ed1206f14ed48a17d00b56403c99dca74d10f575 83d3589bf47eb299fa103ba834bc390e41ba5678
c8ea5013c9c0401903d89d6b403a1d744594bade a781344b9ba14647f95555e84bf38b49a627f24c
57576cb5b70c597cea9576e266101af6778e9dcb 5a853b1b8099f006945ed16da4879debbe1e1683
6bbbf2e4d4f271ebf058dca4ed5d0632051675ff 351bc15959f5c15ff58e3d678689397b5b226c35
11b965e2ce5481d8b0d7cc88100cd768d054ce0e ed51df2fef5e24132ea194899d2204032c291581
eadba3450656ceef32fe09323799657648e7d870 ca177dfb0ce7cff95fd0707f3b26f923c2edd370
248de8768d4fd9067392bad7a90535a9fda39e2c d4a11b708308f69be2d2ce39f7b0bdc50657d9e6
420192f6f3109a7c8ae2a09980b11e4f862c59d2 833ed1dd48c52c5abd9ec5788ecc64931de22eef

Where

Git	HG
ed1206f14ed48a17d00b56403c99dca74d10f575	83d3589bf47eb299fa103ba834bc390e41ba5678
c8ea5013c9c0401903d89d6b403a1d744594bade	a781344b9ba14647f95555e84bf38b49a627f24c
57576cb5b70c597cea9576e266101af6778e9dcb	5a853b1b8099f006945ed16da4879debbe1e1683
6bbbf2e4d4f271ebf058dca4ed5d0632051675ff	351bc15959f5c15ff58e3d678689397b5b226c35
11b965e2ce5481d8b0d7cc88100cd768d054ce0e	ed51df2fef5e24132ea194899d2204032c291581
eadba3450656ceef32fe09323799657648e7d870	ca177dfb0ce7cff95fd0707f3b26f923c2edd370
248de8768d4fd9067392bad7a90535a9fda39e2c	d4a11b708308f69be2d2ce39f7b0bdc50657d9e6
420192f6f3109a7c8ae2a09980b11e4f862c59d2	833ed1dd48c52c5abd9ec5788ecc64931de22eef

marks git

:2 eadba3450656ceef32fe09323799657648e7d870
:12 57576cb5b70c597cea9576e266101af6778e9dcb
:14 420192f6f3109a7c8ae2a09980b11e4f862c59d2
:8 11b965e2ce5481d8b0d7cc88100cd768d054ce0e
:16 c8ea5013c9c0401903d89d6b403a1d744594bade
:4 ed1206f14ed48a17d00b56403c99dca74d10f575
:10 6bbbf2e4d4f271ebf058dca4ed5d0632051675ff
:6 248de8768d4fd9067392bad7a90535a9fda39e2c

marks hg

{"tips": {}, "last-mark": 16, "last-note": 0, "version": 0, "marks": {"83d3589bf47eb299fa103ba834bc390e41ba5678": 4, "a781344b9ba14647f95555e84bf38b49a627f24c": 16, "d4a11b708308f69be2d2ce39f7b0bdc50657d9e6": 6, "351bc15959f5c15ff58e3d678689397b5b226c35": 10, "ed51df2fef5e24132ea194899d2204032c291581": 8, "ca177dfb0ce7cff95fd0707f3b26f923c2edd370": 2, "5a853b1b8099f006945ed16da4879debbe1e1683": 12, "833ed1dd48c52c5abd9ec5788ecc64931de22eef": 14}}

Generate the git-mapfile

Important is the relation not the order it seems

| 2 | eadba3450656ceef32fe09323799657648e7d870 | 2 | ca177dfb0ce7cff95fd0707f3b26f923c2edd370 | | 4 | ed1206f14ed48a17d00b56403c99dca74d10f575 | 4 | 83d3589bf47eb299fa103ba834bc390e41ba5678 | | 6 | 248de8768d4fd9067392bad7a90535a9fda39e2c | 6 | d4a11b708308f69be2d2ce39f7b0bdc50657d9e6 | | 8 | 11b965e2ce5481d8b0d7cc88100cd768d054ce0e | 8 | ed51df2fef5e24132ea194899d2204032c291581 | | 10 | 6bbbf2e4d4f271ebf058dca4ed5d0632051675ff | 10 | 351bc15959f5c15ff58e3d678689397b5b226c35 | | 12 | 57576cb5b70c597cea9576e266101af6778e9dcb | 12 | 5a853b1b8099f006945ed16da4879debbe1e1683 | | 14 | 420192f6f3109a7c8ae2a09980b11e4f862c59d2 | 14 | 833ed1dd48c52c5abd9ec5788ecc64931de22eef | | 16 | c8ea5013c9c0401903d89d6b403a1d744594bade | 16 | a781344b9ba14647f95555e84bf38b49a627f24c |

Result

eadba3450656ceef32fe09323799657648e7d870 ca177dfb0ce7cff95fd0707f3b26f923c2edd370 ed1206f14ed48a17d00b56403c99dca74d10f575 83d3589bf47eb299fa103ba834bc390e41ba5678 248de8768d4fd9067392bad7a90535a9fda39e2c d4a11b708308f69be2d2ce39f7b0bdc50657d9e6 11b965e2ce5481d8b0d7cc88100cd768d054ce0e ed51df2fef5e24132ea194899d2204032c291581 6bbbf2e4d4f271ebf058dca4ed5d0632051675ff 351bc15959f5c15ff58e3d678689397b5b226c35 57576cb5b70c597cea9576e266101af6778e9dcb 5a853b1b8099f006945ed16da4879debbe1e1683 420192f6f3109a7c8ae2a09980b11e4f862c59d2 833ed1dd48c52c5abd9ec5788ecc64931de22eef c8ea5013c9c0401903d89d6b403a1d744594bade a781344b9ba14647f95555e84bf38b49a627f24c

add the hgrc file and the git subdirectory

Source: hg-git-named-branch-only/.hg/hgrc

Source: hg-git-named-branch-only/.hg/git

Target git-hg-remote-named-branch-only/.hg

Now add a commit and push from git-hg-remote-named-branch-only to remote

Merge and push from git-hg-remote-named-branch-only to remote

Pull from git and then add a commit push the to local git-hg-remote-named-branch-only

Everything seems to work fine

So any change to add the functionality to generate the git-mapfile that could one use, obviously at one own's risk, together with hg-git to push directly to the remote git repository?

Thanks