Shipping hg-git by default?

[Harvey Chapman]

> On Sep 29, 2015, at 7:19 PM, Sean Farley <sean at farley.io> wrote:
> 
> 
> 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

Well that sure is easier. Thanks!

Does it still require the gexport or a push?