One thing that is not completely clear to me is if we want to keep backwards compatibility with python2 for the time being. My sensation is we should strive to keep the codebase py2&py3 compatible for the time being.
Hi there, hg-git itself has been a been low on my radar these past few weeks, as I was really focusing on lauchning well, this Heptapod we're discussing on actually. In truth
There are several efforts in the porting to Python 3. A long series has already been pushed here, as the py3-timeless topic, and a few follow-up changesets of mine, as the py3-gracinet topic.
I'll make a merge request, it will be clearer.
I appreciate all the efforts people are willing to do about that. Not really sure how to coordinate them, though. It seems rather counter productive to wait for the whole test suite to pass on Python 3 to accept them: they are just too many changesets.
@gracinet could you please start a Merge Request so that we can discuss there with the actual code?
Personally I think its best to have the whole test suite... or mark the .gitlab-ci.yml job with https://docs.gitlab.com/ee/ci/yaml/#allow_failure so that we can track which test is passing and how it improve overtime.
I am quite surprise as both FB's Eden and Octopus have their own fork of HG-Git, there is none Python3 port that we can leverage :(
In principle, I like the idea of having the CI first, but in this case I don't remember if we even have a single test passing on py3. I could surely bootstrap something, though.
In the past few days, @mjacob has been rebasing and checking a few changesets towards py3 compatibility resulting in MRs that I've accepted: !13 (merged) (patches by @muxator) and !14 (merged)
On top of the nice py3-part3 series I had to removes b-prefixes from the gignorepats to have something working (for hg status). Nice work by the way, I can at least pull/push under py3 !
recently I was lazy, needed to get stuff done, and indulged in using mercurial + hg-git under python2. By the way, hg-git ff226f3f5ec2 works very well under python2 even for advanced workflows (history rewriting, force pushing, etc.). This is a (partial) answer to @fhgd question.
Now that I reinstalled Ubuntu 20.04, I'd like to stay on a pure python3 system, but I fear hg-git still need some attention.
$ hg debugextensions --verbose*** failed to import extension hggit from /opt/mercurial/hg-git/hggit: 'file'
Is there some work currently being done that I can join forces with, or is it ok if I try to propose something on my own?
p.s.: I have to admit that I am confused by the current repo structure: when opened with TortoiseHG I see a lot of heads and it is hard for me to understand what's the current tip (I had no success in catching up with the Evolve extension, which I did not enable).
There are several different branches, including one of mine (!16 (closed)). I integrated some of the changes from the other branches and someone reported that it partially works. I fear that this causes that it’s now blocked on me, but in the moment I neither have the time nor the motivation to finish it.
What would be necessary to consider it finished is of course fixing the tests (see e.g. https://foss.heptapod.net/mercurial/hg-git/-/jobs/70356). What would be a great help would be to find out why sometimes the "tag: default/master" line in the output is missing.
To enable to work efficiently with topics, you’ll need to enable the "topic" extension. To just look at the repository it’s not strictly required. First, everything that is "merged" and "official" is in the "public" phase, while open topics are in the "draft" phase. Second, if you have a sufficiently recent version of TortoiseHg, you can add the "Topic" column to the table of the changesets. Note that while in "hg log" etc., the topic is hidden when a changeset is in the public phase, it’s always shown in TortoiseHg.