Shipping hg-git by default?

Sean Farley sean at farley.io
Tue Sep 29 23:19:06 UTC 2015


Harvey Chapman <hchapman-hg at 3gfp.com> writes:

>> On Sep 29, 2015, at 5:03 PM, Arne Babenhauserheide <arne_bab at web.de> wrote:
>> 
>> Am Dienstag, 29. September 2015, 08:27:23 schrieb anatoly techtonik:
>>>> However, I used it as full-fledged bridge only once, ran into a multitude
>>>> of problems (different hashes, history rewrite is a PITA, no octopus
>>>> merges, etc.), and stopped using it that way.
>>>> 
>>> 
>>> Different hashes can be a problem when you need to reference revisions, but
>>> I never faced with this problem until you said it. Probably hg needs to
>>> mention Git revision number when mirroring remote repo, but it may happen
>>> that the problem is premature.
>> 
>> I’m facing that problem quite often: I clone some repo, work on it and
>> push my changes. Then I ask someone “could you check branch X” and he
>> asks “can you give me the revision number?”
>> 
>> Uh … yes … let me go into .hg/git and do `git log`, using the commit
>> message to find the right hash.
>> 
>> Or someone tells me that this is fixed “in revision abcxyz”. Uhm…
>> 
>> It would be nice if I could tell hg-git to give me the hg revision
>> which corresponds to a speciifc git revision — and vice versa. Maybe
>> even updating to git revisions via -r "git(REV)" or outputting them
>> with --template "{node|git}\n”.
>
>
> $ grep `hg id -r a_branch -i` `hg root`/.hg/git-mapfile
> cc722b68743f2feaa4da658e04e5c06906880b19 26ef09f0094c164f37a4d41919587e54c1534cde
> HG_HASH GIT_HASH

It's actually easier than that:

$ hg log -r HG_HASH -T '{gitnode}'
2f3c30d3d5162b2d4e0c6e502bbf9d0ef3bda10a <- GIT_HASH

To do the reverse lookup:

$ hg log -r 'gitnode(2f3c30d3d5162b2d4e0c6e502bbf9d0ef3bda10a)' -T '{node}'
95a0cb51dec980b0475067f20e01cfd12898341b <- HG_HASH



More information about the Mercurial mailing list