On 12/21/20 11:46 AM, Dan Villiom Podlaski Christiansen wrote:
> On 20 Dec 2020, at 23.05, Georges Racinet <
georges...@octobus.net> wrote:
>> Hi Dan,
>>
>> On 12/20/20 8:36 PM, Dan Villiom Podlaski Christiansen wrote:
>>
>>> Since I was recently made co-maintainer of the project, I figured I’d share my thoughts for the future, and perhaps we could start a discussion on how to proceed.
>>>
>>> My main perspective on hg-git is as a user; given that Git won the VCS “war” it’s rather unusual for me to clone actual Mercurial repositories — apart from those used for Mercurial-related projects. Instead, I use hg-git as a daily driver, both in my spare time and at work. In my experience, hg-git has some rather serious issues when used like that, and I’ve attempted to address them, in particular in one MR.[1]
>>>
>>> Since my last message to list, most of my MRs received review and approval — and that's great! Unfortunately however, not much has happened since then, and I now have eight MRs pending again. I'd appreciate some feedback on how to proceed — should I just merge them without review?
>> Since the work you've done on the CI setup, I've been busy full time
>> with Heptapod development, in particular to meet tomorrow's deadline for
>> version 0.18.0. Now that is almost done: the pipeline doing that release
>> is running as I'm writing this.
>>
>> I should be able to do some hg-git work tomorrow after install on
>>
foss.heptapod.net and on Tuesday. I know, 10 days ago I was saying
>> something alike, but there was acceleration with respect to some subjects.
> I know we all have day jobs and that hg-git usually isn't part of it, but it is a bit frustrating to wait a week or more without any response at all. If you could spare the time, something like a confirmation that you've seen the MR or a high-level comment would be much appreciated!
Yes, I'll try and do better with that.
>
>>> Should we add other maintainers or reviewers?
>> We should certainly avoid a repeating pattern of people stepping up
>> (like you did) and getting tired. Not saying we are there right now, of
>> course. I am personally open to a bigger pool of maintainers.
> I don't if they're on this list, or even interested, but muxator has been providing good contributions and feedback. Perhaps that's another candidate.
Noted, thanks.
>
>>> It seems to me that the changes already in — and some of those pending — contain useful bug fixes, and it would be nice to get a release out. Who has the keys to do so?
>> Currently, Kevin Bullock, Manuel Jacob and me.
>>
>> I've gained the ability to appoint people on PyPI 6 weeks ago, and
>> transferred it to Manuel immediately.
>>
>>> Since the changes are relatively minor, I'd propose cutting a 0.9.1,
>> Yes, I can do that.
>>> and then getting started on 1.0. Some areas I'd like to improve hg-git are:
>>>
>>> * Prune remote references, and outdated bookmarks while at it.
>>>
>>> * Make a bare push safe; don't create branches/bookmarks unless requested by the user.
>>>
>>> * Create binary archives for Ubuntu — or just binary Python wheels.
>> As far as I understand, the question of wheels would be fairly trivial
>> for hg-git itself, since it is pure Python. But Mercurial does not
>> publish wheels yet (the question was raised I believe a few times), and
>> I don't know about dulwich (it has a small amount of C code, too).
> I opened an issue with Dulwich — it has Windows wheels, but nothing for Linux. The only discussion I could find relating to Mercurial was from 2017, though.[*] The LaunchPad PPA also seems quite out of date[†] — that was my go-to solution previously.
>
> AFAICT GitLab (and thus Heptapod?) actually has support for PyPI repositories.[‡]
Yes, it should be rather orthogonal to the changes we've done for
Heptapod, hence I hope it'd work right away, but I haven't tried it yet.
> Perhaps enabling that as an interim solution would work? Then packages and wheels could be manually published to PyPI.
If you have in mind something fully automatic based on tag pipelines,
there's also the question of PGP signatures. Previous releases were
signed with the `gpg` extension, and I've done the same for the ones I
did. Fortunately, the changeset with the signature is after the tag, so
that we can tackle the two questions of pushing a package and of the
signature separately.
I'm not against using the `git` executable for this, and was actually
wondering if you had that in mind. It's nice for hg-git to work without
Git, but it probably shouldn't prevent doing some additional stuff if
`git` is actually available. That's fairly common after all.
To state the obvious, in the case of GC, it should be controlled by
dedicated options. For example, in GitLab (hence Heptapod), Git garbage
collecting is already taken care of by scheduled background jobs with a
locking system to present concurrent writes.
> I've personally run into this, and the failure mode is rather annoying: In some cases, Dulwich just hangs.
Just to make sure: you mean that because presumably of the size of the
`.hg/git` repo, hg-git stopped working at some point?
>
> [*]
https://foss.heptapod.net/mercurial/hg-git/-/merge_requests/63
>
>>> * Can we transfer tags between Mercurial clones?
>> There was a brainstorming about tags at the November Mercurial sprint.
>> Maybe new possibilities will arise from there and/or the landscape will
>> change enough that we need to keep an eye on that, but I'll have to
>> check if something concrete is in the works.
>>> * Can we transfer the Git commit IDs/map/state between clones?
>>>
>>> I'm not sure how to achieve the latter two, and they're sort of longer-term goals for me.
>> The last one includes what is in my eyes the most important issue:
>> changeset stability in the Git to Mercurial conversion. In practice,
>> that turns hg-git users into isolated islands. I don't want to give you
>> false hopes, but there's a tiny tiny chance I'd have a lead on that –
>> call that a hunch at this point.
>>
>> Exchanging the map would be a mere nice-to-have for comparison, useful
>> only for bigger repos, I suppose.
> I have some automatic conversions set up on a server of my own. In most cases, the conversions are indeed stable,
In the cases I care about in the Git -> Mercurial direction, it's never
been stable but these are heavy and complicated repos (GitLab…) and I've
been backuping those map files systematically after I noticed this,
hence sidestepped the problem.
> but it would be nice to be able to transfer the Git identity with a commit. A personal goal for me is to have mercurial+hg-git reach a state where I could say to co-workers: “Yes, you really should use Mercurial; it's a better Git client than git.” For that to be the case, two clones should _always_ have the same Git state, regardless of configuration, etc., and I don't see how we can provide that guarantee without transferring the commit map.
Yes, perhaps you're right and doing that is the only way that can be
robust enough, but it raises a few questions of its own: the map file is
mostly appending – except there's a command to clean it. As you were
saying, it's a longer term goal.
>
>> I'd like to introduce testing with my mercurial-testhelpers [1] library,
>> as I think it would help solving these deep questions. Basically, it
>> should be efficient for hg-git for the same reasons it is for Heptapod
>> components. For example, last week, I've written a pytest fixture [3]
>> that manages a pair of Mercurial and Git repos. It could easily be used
>> in local pull/push scenarios.
> To be honest, I don't really have any issues with the current testsuite which, unlike the Mercurial tests, do run reasonably quickly, even on a Mac. But making testing easier is always good 🙂
Yes, in the case of hg-git, running time is not the issue. It's more
about being at the heart of things rather than seeing all the action
from a shell script.
>
> Speaking of which, you might want to look at MR 63[*] — to ensure that cloning over the network, actually, properly worked, I added a test using a CI service exposing a Git repository over the Git, SSH and HTTP protocols, the latter with authentication.
Sound nice
>
> [*]
https://github.com/libgit2/libgit2/issues/3247
>
>>> But as part of planning a more significant release, I'd also propose dropping support for Python 2.7 and severely pruning the Mercurial versions supported.
>> I would be supportive of that move if you feel so, and it really makes
>> sense if the project maintainers are already too busy.
>>
>> That being said, I'd like to hear wider feedback on that, in particular,
>> what would be the minimal version that wouldn't cut off our user base?
>>
>>> Deeper changes, such as migrating away from bookmarks or optimising the core, would be nice, but I don't consider them all that important. In my experience, the core logic essentially works, and works quite well.
>>>
>>> Anyway, I hope there's someone out there willing to discuss this 🙂
>> I certainly am.
>>
>> Thanks for all the work you've been doing so far.
> And likewise on Heptapod — it's great 🙂
:-)
Let's get on with it, now.