hg-git 1.0.0 released

[Dan Villiom Podlaski Christiansen]

Hi,

I've just pushed the first stable release of the 1.0 series to PyPI and
Heptapod:

https://pypi.org/project/hg-git/1.0.0
https://foss.heptapod.net/mercurial/hg-git/-/releases/1.0.0

Relative to the earlier betas, this release also includes the following
bug fixes:

* Handle errors in ``.gitmodules`` gracefully, allowing the conversion
to continue. (#329)
* Don't die with an error when ``.hgsub`` contains comments. (#128)
* Suppress errors on export related to history editing of certain
commits with unusual authorship and messages. (#383)
* Fix tests with Git 2.35.

Other changes:

* Increase test coverage by using different versions of Alpine Linux
and Dulwich.

This release requires Mercurial 5.2 or later and Python 3.6 or later.

The full list of changes in 1.0 includes those in the betas, included
below. Thanks to everyone who helped review and test the changes in this
release!

- Dan

--

hg-git 1.0b2 (2022-03-10)
=========================

This is a follow-up to the previous beta, that fixes the following
bugs:

* Fix tests with Mercurial 6.1.
* Avoid prompting for authentication after a successful push, by
storing the authenticated client. (#379)

This release requires Mercurial 5.2 or later and Python 3.6 or later.

hg-git 1.0b1 (2022-01-26)
=========================

This is a preview of an upcoming major release that contains changes
to user-facing behaviour, as well as a fair amount of internal
changes. The primary focus is on adjusting the user experience to be
more intuitive and consistent with Git and Mercurial. The internal
changes are mainly refactoring to make the code more consistent and
maintainable. Performance should also be much better; a simple clone
of a medium-sized repository is about 40% faster.

This release requires Mercurial 5.2 or later and Python 3.6 or later.

Changes to behaviour:

* When a pull detects that a Git remote branch vanishes, it will
remove the corresponding local tags, such as ``default/branch``.
This is equivalent to using ``git fetch --prune``, and adjustable
using the ``git.pull-prune-remote-branches`` configuration option.
* Similarly, delete the actual bookmarks corresponding to a remote
branch, unless the bookmarks was moved since the last pull from Git.
This is enabled by default and adjustable using the
``git.pull-prune-bookmarks`` configuration option.
* Speed up ``pull`` by using a single transaction per map save
interval.
* Similarly, speed up ``hg clone`` by always using a single
transaction and map save interval, as Mercurial will delete the
repository on errors.
* Change the default ``hggit.mapsavefrequency`` to 1,000 commits rather
than just saving at the end.
* Abort with a helpful error when a user attempts to push to Git from
a Mercurial repository without any bookmarks nor tags. Previously,
that would either invent a bookmark —— *once* — or just report that
nothing was found.
* Only update e.g. ``default/master`` when actually pulling from
``default``.

Enhancements:

* Add a ``gittag()`` revset.
* Print a message describing which bookmarks changed during a pull.
* Let Mercurial report on the incoming changes once each transaction
is saved, similar to when pulling from a regular repository.
* Remove some unnecessary caching in an attempt to decrease memory
footprint.
* Advance phases during the pull rather than at the end.
* With ``hggit.usephases``, allow publishing tags and specific remotes
on pull, as well as publishing the remote ``HEAD`` on push.
* Change defaults to drop illegal paths rather than aborting the
conversion; this is adjustable using the ``hggit.invalidpaths``
configuration option.
* Allow updating bookmarks from obsolete commits to their successors.

Bug fixes:

* Adjust publishing of branches to correspond to the documentation.
Previously, e.g. listing ``master`` would publish a local bookmark
even if diverged from the remote.
* Handle corrupt repositories gracefully in the ``gverify`` command,
and allow checking repository integrity.
* Only apply extension wrappers when the extension is actually
enabled rather than just loaded.
* Fix pulling with ``phases.new-commit`` set to ``secret``. (#266)
* Detect divergence with a branch bookmark suffix.
* Fix flawed handling of remote messages on pull and push, which
caused most such messages to be discarded.
* Report a helpful error when attempting to push or convert with
commits missing in the Git repository. Also, issue a warning when
creating a new Git repository with a non-empty map, as that may lead
to the former.
* Ensure that ``gimport`` also synchronises tags.
* Address a bug where updating bookmarks might fail with certain
obsolete commits.
* Handle missing Git commits gracefully. (#376)

Other changes:

* Require ``setuptools`` for building, and use ``setuptools_scm`` for
determining the version of the extension.
* Refactoring and reformatting of the code base.

[Raffaele Salmaso]

On Sat, Apr 2, 2022 at 9:53 PM Dan Villiom Podlaski Christiansen <dan...@gmail.com> wrote:

I've just pushed the first stable release of the 1.0 series

Thanks!

🎉

--

| Raffaele Salmaso
| https://salmaso.org

| https://github.com/rsalmaso

[Dr. Arne Babenhauserheide]

Dan Villiom Podlaski Christiansen <dan...@gmail.com> writes:
> I've just pushed the first stable release of the 1.0 series to PyPI
> and Heptapod:
>
> https://pypi.org/project/hg-git/1.0.0
> https://foss.heptapod.net/mercurial/hg-git/-/releases/1.0.0

Wow — huge kudos to that! Thank you!

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[Uwe Brauer]

>>> "DVPC" == Dan Villiom Podlaski Christiansen <dan...@gmail.com> writes:

Hello

> Hi,
> I've just pushed the first stable release of the 1.0 series to PyPI and
> Heptapod:

Thanks, as far as I can see, named branches are, still, not supported in
that release, right?
Only in the topic branch «branches-and-stuff»?

But I also note that in the latest changesets you drop support for 5.2,
and python 3.6, so if you merge, then named branch would only work if
those requirements are met....

Uwe Brauer

[Dan Villiom Podlaski Christiansen]

On 3 Apr 2022, at 08.39, Uwe Brauer <o...@mat.ucm.es> wrote:

>>>> "DVPC" == Dan Villiom Podlaski Christiansen <dan...@gmail.com> writes:
>
> Hello
>
>> Hi,
>> I've just pushed the first stable release of the 1.0 series to PyPI and
>> Heptapod:
>
> Thanks, as far as I can see, named branches are, still, not supported in
> that release, right?
> Only in the topic branch «branches-and-stuff»?

That's correct; I need to figure out how to handle detached tags before merging that branch. I added a test that shows the behaviour, but I haven't come up with any good solution yet, sadly.

> But I also note that in the latest changesets you drop support for 5.2,
> and python 3.6, so if you merge, then named branch would only work if
> those requirements are met....

It's in a topic, so not merged yet 🙂 I noticed that Mercurial will keep Python 3.6 support for a while as it seems somewhat widespread even if unsupported by the Python maintainers. Would either of those requirements cause problems for you?

--

Dan Villiom Podlaski Christiansen
dan...@gmail.com — +45 2728 9771

[Uwe Brauer]

> On 3 Apr 2022, at 08.39, Uwe Brauer <o...@mat.ucm.es> wrote:

> That's correct; I need to figure out how to handle detached tags
> before merging that branch. I added a test that shows the behaviour,
> but I haven't come up with any good solution yet, sadly.

Hm, I am not sure what you mean by this. So far I am using named
branches for the emacs-matlab repository which sadly is under git, and I
have not faced any problems. If I have the time I'd like to give that
test a try.

> It's in a topic, so not merged yet 🙂 I noticed that Mercurial will
> keep Python 3.6 support for a while as it seems somewhat widespread
> even if unsupported by the Python maintainers. Would either of those
> requirements cause problems for you?

Actually I am still bound to Ubuntu 16.04[1] which only ships 3.5 😨
I tried several times to install also 3.7 or 3.8 but it caused all sort
of problems.

To upgrade hg 5.2 should not be a problem but I had problems with 5.5
compiled for 3.5: pushing and pulling to local clones gave me some
errors.
Not sure who the culprit is.

Anyhow, right now I still with 5.2 for daily work and use 5.5 and the
branch-and-stuff topic only if I need to deal with matlab-emacs,
inconvenient but doable.

Uwe


Footnotes:
[1] and don't want to take the risk to upgrade to say 20.04 before the
academic course end in the first week of may (or maybe wait till
the exams period is finished at the end of June.)

--
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military.
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine.