hg-git 1.1.4 & 1.2.0b1 released

[Dan Villiom Podlaski Christiansen]

Hi

I'm pleased to announce two new releases for hg-git. One is a regular
compatibility release, and one is an initial beta of 1.2.0. The latter
is _quite_ overdue, and I can't say when the final release will be, as
it depends on the feedback — it'll be at least a month after a beta with
no major issues reported.

And just to be clear: Any feedback is very much appreciated! I've been
developing hg-git mostly in my own little sandbox, and I may very well
have gotten stuff like option names — and whether they should be enabled
by default — wrong. Or I might have written some horribly broken code;
who knows? Anyway; please report back!

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

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

hg-git 1.1.4 (2024-11-18)
=========================

This is a minor release, focusing on bugs and compatibility.

* Mark Dulwich 0.22.0 as fully supported; the differences are assumed
  intentional for now.
* Mark Mercurial 6.9 as tested and supported.
* Fix tests with Python 3.13.

hg-git 1.2.0b1 (2024-11-18)
===========================

This is a preview of an upcoming feature release that contains changes
to user-facing behaviour.

Changes to behaviour:

* Change the defaults for ``hggit.usephases``; similar to Mercurial,
  remote repositories now default to publishing.

Enhancements:

* Add support for a ``git.blame.ignoreRevsFile`` configuration
  setting, that works similarly to the setting for ``git blame``.
* Add limited and experimental support for including hg-git metadata
  in Mercurial bundles and when pulling or pushing from remote
  Mercurial repositories, see below. (#156)
* ``hg git-cleanup`` now also removes broken Git refs.
* Always pull any annotated tags pointing to any known commits,
  equivalent to passing the ``--tags`` option in Git. Previously, such
  tags would only be pulled when either not using ``--rev`` or
  similar, or when listing the tag explicitly.
* Transparently compress the objects when pushing (or exporting) to
  Git. This is done in background threads, and by default uses up to
  either four of them or the system CPU count, whichever is lower. The
  ``hggit.threads`` configuration option allows adjusting the default.

This release requires Mercurial 6.6, or later, Dulwich 0.21.6 or later
and Python 3.8 or later.

Transferring ``hg-git`` metadata
--------------------------------

As noted, this is experimental, and can be enabled using the following
configuration settings::

  [experimental]
  hg-git-bundle = yes
  hg-git-serve = yes

With these set, pulling or pushing any commit already pushed (or
converted) to Git will also update the mapping remotely, avoiding the
need for converting these changes once more. In addition, Git tags are
also transferred. However, this support is limited, and there is no
synchronisation of later changes. There is no support for reinstating
or synchronising lost or old state, and no support for transferring
tags to old changesets.

The first option enables embedding the metadata using ``hg bundle``
and the second option enables the support with served repositories.

[Uwe Brauer]

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

> Hi
> I'm pleased to announce two new releases for hg-git. One is a regular
> compatibility release, and one is an initial beta of 1.2.0. The latter
> is _quite_ overdue, and I can't say when the final release will be, as
> it depends on the feedback — it'll be at least a month after a beta
> with no major issues reported.

Any changes that at least the named-branch support will be merged into the official release.

I am using it now for several month, and it is quite good, there are
some specific problems, I am very rarely confronted with, but can't
circumvent them by pushing with the -b option.


The topic support I am afraid does not work very well at least not with
github. Github rejects any commit that has a mercurial topic.

--
I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military.
I support the EU and NATO membership of Ukraine.

[Dan Villiom Podlaski Christiansen]

On 18/11/2024 19.40, Uwe Brauer wrote:

>>>> "DVPC" == Dan Villiom Podlaski Christiansen <dan...@gmail.com> writes:
>> Hi
>> I'm pleased to announce two new releases for hg-git. One is a regular
>> compatibility release, and one is an initial beta of 1.2.0. The latter
>> is _quite_ overdue, and I can't say when the final release will be, as
>> it depends on the feedback — it'll be at least a month after a beta
>> with no major issues reported.
>
> Any changes that at least the named-branch support will be merged into the official release.
>
> I am using it now for several month, and it is quite good, there are
> some specific problems, I am very rarely confronted with, but can't
> circumvent them by pushing with the -b option.
>
>
> The topic support I am afraid does not work very well at least not with
> github. Github rejects any commit that has a mercurial topic.

I haven't had much time for hg-git development lately and wanted to get
the 1.2 beta out, but I hope to return to it at some point. But your
feedback is much appreciated; maybe I should try to strive for less, and
just try to get branch mode working?

- Dan

[Uwe Brauer]

I'd love to help, since I consider it such an important feature. I was
surprised the importing git branches also works, (it relies it seems on
git's name-rev, right? That has its short comings, but that cannot be
avoided.

> maybe I should try to strive for
> less, and just try to get branch mode working?

That would be a first important step. It would be also allow the latest
hg-git versions, because right now I stick to the changeset 13cf16d4c84f


On the other hand the problem of named-branches is that they don't have
namespaces.
So I have to be careful when contributors in a repository I also
maintain don't select a name of a branch that could cause a name
conflict.

In that sense topics would be more natural and appropriate. (The only
annoying design decision for me is, to make them invisible once a the
changeset is public (I need the --debug option to see public topics)

Github plainly rejects topics claiming that they are fancy git
references.

I can provide more information if necessary

Uwe

[Dan Villiom Podlaski Christiansen]

On 18/11/2024 20.50, Uwe Brauer wrote:

>> On 18/11/2024 19.40, Uwe Brauer wrote:
>
>> I haven't had much time for hg-git development lately and wanted to
>> get the 1.2 beta out, but I hope to return to it at some point. But
>> your feedback is much appreciated;
> I'd love to help, since I consider it such an important feature. I was
> surprised the importing git branches also works, (it relies it seems on
> git's name-rev, right? That has its short comings, but that cannot be
> avoided.

Well, sort of; there's a heuristic that follows each Git “branch”
backwards, but tries hard to let the default branch win. So it's not
technically based on `name-rev`, but does most of the same 🙂 If you
never delete the branch refs, they should get the right name.

>> maybe I should try to strive for
>> less, and just try to get branch mode working?
> That would be a first important step. It would be also allow the latest
> hg-git versions, because right now I stick to the changeset 13cf16d4c84f
>
>
> On the other hand the problem of named-branches is that they don't have
> namespaces.
> So I have to be careful when contributors in a repository I also
> maintain don't select a name of a branch that could cause a name
> conflict.

I toyed around with the thought of a Heptapod-like mode where you'd have
the three different namespaces for branches, topics and bookmarks. But
actually implementing it in the current codebase seems near-impossible
to me, sorry… I think it's another case where you just have to be aware
of the two systems involved…

> In that sense topics would be more natural and appropriate. (The only
> annoying design decision for me is, to make them invisible once a the
> changeset is public (I need the --debug option to see public topics)
>
> Github plainly rejects topics claiming that they are fancy git
> references.
>
> I can provide more information if necessary

Please do — I don't think I tried pushing anything to Github, so I
haven't seen the error myself. Feature-wise the main issues are:

* How to handle detached tags? I've tried to make them work, but not
100% sure I got it right.

* How to close branches or topics when merged? For bookmarks, just
pushing a non-existent bookmark by name using `-B` will work, but
there's no similar support for branches, where it ought to be possible.
How to detect a “closed” topic seems less obvious to me…

But again, I didn't test it out all that much myself. Now that the 1.2
beta is out, I might try it out for some of my own, daily repositories
and see how it goes.

- Dan

[Uwe Brauer]

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

> On 18/11/2024 20.50, Uwe Brauer wrote:
>> I'd love to help, since I consider it such an important feature. I was
>> surprised the importing git branches also works, (it relies it seems on
>> git's name-rev, right? That has its short comings, but that cannot be
>> avoided.

> Well, sort of; there's a heuristic that follows each Git “branch”
> backwards, but tries hard to let the default branch win. So it's not
> technically based on `name-rev`, but does most of the same 🙂 If you
> never delete the branch refs, they should get the right name.

Just to make sure we talking here about the same: git has no way to
determine the branch point as even the most enthusiastic git supporter
(and mercurial skeptical Felipe Contreras admits.

https://felipec.wordpress.com/2013/08/27/analysis-of-hg-and-git-branches/
Section Fixing git, and

https://felipec.wordpress.com/2013/08/27/analysis-of-hg-and-git-branches/

And Felipe's proposed solution that was never accepted.

https://github.com/felipec/git/commits/fc/tail

Where git fails can be seen in this example

--8<---------------cut here---------------start------------->8---
git init foo-git
cd foo
echo 1 > 1
git add 1
git commit -m "First commit in master"
echo 1.1 > 1
git add .
git commit -m "Second commit in master"
git checkout -b feature master~1
echo 1.2 > 1
git add .
git commit -m "First commit in feature"
echo 1.2.1 > 1
git add .
git commit -m "Second comit in feature"
git checkout master
git merge feature
echo 1.2.1/1.1 > 1
git add .
git commit -m "Merged feature in master"
--8<---------------cut here---------------end--------------->8---

Then
git log --graph --decorate --pretty=short | git name-rev --annotate-stdin

Results in
--8<---------------cut here---------------start------------->8---
* commit 84b337af54903763d7b54f54d145e1eb3c918d4a (master) (master)
|\ Merge: 9f2346c 68df6e5
| | Author: Uwe Brauer <o...@mat.ucm.es>
| | Date: Wed Jul 19 21:28:40 2023 +0200
| |
| | Merged feature in master
| |
| * commit 68df6e5a25a4420ffa9347e31d3b9ceedc71eb03 (feature) (HEAD -> feature)
| | Author: Uwe Brauer <o...@mat.ucm.es>
| | Date: Wed Jul 19 21:28:40 2023 +0200
| |
| | Second comit in feature
| |
| * commit d6a642b5c924f9f6aea42dbe942e50459ab46d3d (feature~1)
| | Author: Uwe Brauer <o...@mat.ucm.es>
| | Date: Wed Jul 19 21:28:40 2023 +0200
| |
| | First commit in feature
| |
* | commit 9f2346c87ce46d7f05b9fdf2f2565531fde0e49d (master~1)
|/ Author: Uwe Brauer <o...@mat.ucm.es>
| Date: Wed Jul 19 21:28:40 2023 +0200
|
| Second commit in master
|
* commit a66433476e579b7d8869cfc27aed0bb2287dacdd (feature~2)
Author: Uwe Brauer <o...@mat.ucm.es>
Date: Wed Jul 19 21:28:39 2023 +0200

First commit in master
--8<---------------cut here---------------end--------------->8---

Which is incorrect

The commit a66433476e579b7 should be in the branch master not in
feature.

Anyhow you know all this stuff much better than me, I just wanted to be
sure that we are talking about the same

> I toyed around with the thought of a Heptapod-like mode where you'd
> have the three different namespaces for branches, topics and
> bookmarks. But actually implementing it in the current codebase seems
> near-impossible to me, sorry… I think it's another case where you just
> have to be aware of the two systems involved…

Yes I know, and for example remote branch tracking sounds wonderful but
the way it is implemented in git, is, well, confusing

>> In that sense topics would be more natural and appropriate. (The only
>> annoying design decision for me is, to make them invisible once a the
>> changeset is public (I need the --debug option to see public topics)
>>
>> Github plainly rejects topics claiming that they are fancy git
>> references.
>>
>> I can provide more information if necessary

> Please do — I don't think I tried pushing anything to Github, so I
> haven't seen the error myself. Feature-wise the main issues are:

Ok I will send that later.

> * How to handle detached tags? I've tried to make them work, but not
> 100% sure I got it right.

Ah BTW, the hg-git version I use (changeset 13cf16d4c84f) seems to have
a problem with tags.

I added a hg tag which resulted in new commit and pushed to github,
pulled then with git to my local git repository but no (git)tag was
created it seems.

> * How to close branches or topics when merged? For bookmarks, just
> pushing a non-existent bookmark by name using `-B` will work, but
> there's no similar support for branches, where it ought to be
> possible. How to detect a “closed” topic seems less obvious to me…

Ok I have to admit that even in mercurial I very seldom close branches,
but then the repositories I use for my daily work a fairly small with
just a handful of named branches.

> But again, I didn't test it out all that much myself. Now that the 1.2
> beta is out, I might try it out for some of my own, daily repositories
> and see how it goes.

If you decide to merge 13cf16d4c84f and release a new version I would
be more than happy to test things, but right now in order to maintain
emacs-matlab on github, I need the named branch support and cannot
benefit form any new features or fixes.



> - Dan

[PIERRE AUGIER]

Thanks a lot Dan for these releases! I'm glad that hggit.usephases becomes the default with hg-git 1.2.0. Commits in master (or main) will be public which is very reasonable in most cases. I just see a consequence that to be able to modify commits, one has to use a dedicated git branch for a feature even when pushing to a personal fork. I always do that but it is not strictly necessary.

Since I can afford the risk, I'm going to use

$ hg version -v
Mercurial Distributed SCM (version 6.9rc1)

Enabled extensions:

absorb internal
churn internal
evolve external 11.1.5
extdiff internal
graphlog internal
hggit external 1.2.0b1 (dulwich 0.21.7)
rebase internal
topic external 1.1.5

Note that I updated Mercurial with

pipx upgrade mercurial --pip-args=--pre

(No compilation since it installs a wheel!)

and hg-git and hg-evolve with :

pipx inject mercurial hg-evolve hg-git --pip-args="--pre -U" --force


----- Mail original -----
> De: "Dan Villiom Podlaski Christiansen" <dan...@gmail.com>
> À: "mercurial" <merc...@mercurial-scm.org>, "hg-git" <hg-...@googlegroups.com>
> Envoyé: Lundi 18 Novembre 2024 19:32:08
> Objet: hg-git 1.1.4 & 1.2.0b1 released

> _______________________________________________
> Mercurial mailing list
> Merc...@lists.mercurial-scm.org
> https://lists.mercurial-scm.org/mailman/listinfo/mercurial

[Malcolm Matalka]

Thank you! I just want to re-iterate that I use hg-git everyday and it is fundamental to my daily sanity. I appreciate the hard work that the team does.

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

> [[PGP Signed Part:Undecided]]