hg-git 0.10.0 released

[Dan Villiom Podlaski Christiansen]

Hi,

We've just pushed a new release of hg-git to PyPI and Heptapod:

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

This release contains a fair amount of changes, as described below. If
you're a user of hg-git, we'd encourage you to subscribe to the mailing
list at <https://groups.google.com/g/hg-git>.

Contributors to this release:

* Dan Villiom Podlaski Christiansen
* Georges Racinet
* Manuel Jacob
* muxator
* Tristan Seligmann

Thanks to everyone who took part in getting this release done, including
users who filed bug reports.


hg-git 0.10.0 (2020-02-01)
==========================

The 0.10.x series will be the last one supporting Python 2.7 and
Python 3.5. Future feature releases will only support Python 3.6 and
later and Mercurial 5.2 or later.

Enhancements:

* Add support for proper HTTP authentication, using either
``~/.git-credentials`` or just as with any other Mercurial remote
repository. Previously, the only place to specify credentials was in
the URL.
* Add ``--git`` option to ``hg tag`` for creating lightweight Git tags.
* Always show Git tags and remotes in ``hg log``, even if marked as
obsolete.
* Support ``{gitnode}`` keyword in templates for incoming changes.
* Support HTTP authentication using either the Mercurial
configuration, ``git-credentials`` or a user prompt.
* Support accessing Git repositories using ``file://`` URIs.
* Optimise writing the map between Mercurial and Git commits.
* Add ``debuggitdir`` command that prints the path to the cached Git
repository.

Bug fixes:

* Fix pulling changes that build on obsoleted changesets.
* Fix using ``git-cleanup`` from a shared repository.
* Fix scp-style “URIs” on Windows.
* Fix ``hg status`` crashing when using ``.gitignore`` and a directory
is not readable.
* Fix support for ``.gitignore`` from shared repositories and when
using a Mercurial built with Rust extensions.
* Add ``brotli`` to the list of modules ignored by Mercurial's
``demandimport``, so ``urllib3`` can detect its absence on Python 2.7.
* Fix the ``git`` protocol on Python 3.
* Address a deprecation in Dulwich 0.20.6 when pushing to Git.
* Fix configuration path sub-options such as ``remote:pushurl``.
* Fix pushing to Git when invalid references exist by disregarding
them.
* Always save the commit map after an import.
* Add support for using Python 3 on Windows.
* Mark ``gimport``, ``gexport`` and ``gclear`` as advanced as they are
either complicated to understand or dangerous.
* Handle backslashes in ``.gitignore`` correctly on Windows.
* Fix path auditing on Windows, so that e.g. ``.hg`` and ``.git``
trigger the appropriate behaviour.

Other changes:

* More robust tests and CI infrastructure.
* Drop support for Mercurial 4.3.
* Updated documentation.

[Georges Racinet]

On 2/1/21 6:56 PM, Dan Villiom Podlaski Christiansen wrote:
> We've just pushed a new release of hg-git to PyPI and Heptapod:
>
> https://pypi.org/project/hg-git/0.10.0/
> https://foss.heptapod.net/mercurial/hg-git/-/releases/0.10.0/

and I'd like to thank you personally for your involvement in hg-git and
the energy you've spent for this release to happen. Congrats!

(I've also granted Dan upload rights on pypi.org for hg-git)

--
Georges Racinet
https://octobus.net, https://about.heptapod.host, https://heptapod.net
GPG: BF5456F4DC625443849B6E58EE20CA44EF691D39, sur serveurs publics

[Raffaele Salmaso]

On Mon, Feb 1, 2021 at 6:56 PM Dan Villiom Podlaski Christiansen <dan...@gmail.com> wrote:

Hi,

We've just pushed a new release of hg-git to PyPI and Heptapod:

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

Thanks!

--

| Raffaele Salmaso
| https://salmaso.org
| https://bitbucket.org/rsalmaso
| https://github.com/rsalmaso

[Malcolm Matalka]

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

> Hi,
>
> We've just pushed a new release of hg-git to PyPI and Heptapod:
>
> https://pypi.org/project/hg-git/0.10.0/
> https://foss.heptapod.net/mercurial/hg-git/-/releases/0.10.0/

Thank you! I use hg-git every single day and my life would be much more
challenging and less enjoyable without it!

[Uwe Brauer]

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

> Hi,
> We've just pushed a new release of hg-git to PyPI and Heptapod:

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

Thanks very much, as others pointed out, the sad truth is that without
hg-git one would be almost isolated from most of the open/free software projects.

BTW, since I see that Manuel Jacob is in the team:

His patch that supports either named branches or topics
changesets
8045105764b and bc1841341adb

From 2019 are still not merged into this release?

Regards

Uwe Brauer

[aurélien campéas]

Thanks a lot for your work !

Aurélien

--
You received this message because you are subscribed to the Google Groups "hg-git" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hg-git+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hg-git/eb332a00-77a3-5ba4-5a30-c8e380d57b70%40gmail.com.

[Dr Rainer Woitok]

Dan,

On Monday, 2021-02-01 18:56:12 +0100, you wrote:

> ...

> We've just pushed a new release of hg-git to PyPI and Heptapod:

After updating my local repository clone I ran "make tests". All tests
run succeeded, but six tests were skipped:

Skipped test-check-pyflakes.t: missing feature: Pyflakes python linter
Skipped test-git-submodules.t: missing feature: dulwich
Skipped test-gitignore-windows.t: missing feature: Windows
Skipped test-networking.t: skipped
Skipped test-pull.t: missing feature: dulwich
Skipped test-renames.t: missing feature: dulwich

I accept that tests "test-check-pyflakes.t", "test-gitignore-windows.t",
and "test-networking.t" were skipped, but the message

missing feature: dulwich

from the other three skipped tests slightly bothers me. What precisely
does that mean? Should I worry?

Background information:

Dulwich, too, lives in a local source repository here, and was built
using

pip install --user .

which installs into "~/.local/". Therefore I have set in my shell

export PYTHONPATH=~/.local/lib/python3.8

and Mercurial seems to find both, Hg-Git and Dulwich:

$ hg -v --version
Mercurial Distributed SCM (version 5.6.1+6-a037f2d114cf)
(see https://mercurial-scm.org for more information)

Copyright (C) 2005-2020 Matt Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Enabled extensions:

convert internal
hggit external 0.10.0 (dulwich 0.20.15)
histedit internal
mq internal
strip internal
uncommit internal
$

Ah, and before I forget: In order to run "make tests" I again had to
apply the following patch:

$ hg diff -c.
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
PYTHON=python
HG=$(shell which hg)
-HGPYTHON=$(shell $(HG) hg debuginstall -T '{pythonexe}')
+HGPYTHON=$(shell $(HG) debuginstall -T '{pythonexe}')
TESTFLAGS ?= $(shell echo $$HGTESTFLAGS)

help:
$

Sincerely,
Rainer

[Dan Villiom Podlaski Christiansen]

I haven't heard from Manuel since before Christmas, I think; he's probably been busy. Anyway, I've rebased and pushed the topics.

As to the change itself, it seems like a bit of a hack to me, so I'd be reluctant to apply it as-is.

--

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

[Dan Villiom Podlaski Christiansen]

On 2 Feb 2021, at 19.24, Dr Rainer Woitok <rainer...@gmail.com> wrote:

> I accept that tests "test-check-pyflakes.t", "test-gitignore-windows.t",
> and "test-networking.t" were skipped, but the message
>
> missing feature: dulwich
>
> from the other three skipped tests slightly bothers me. What precisely
> does that mean? Should I worry?

If Dulwich truly wasn't available, almost all of the tests would fail, and you wouldn't be able to interact with _any_ Git repository. So this is something internal to the test suite, and I'm not sure why those three tests happen to fail. I suspect it's something about the path or $PYTHON location that's going wrong.

I'll try to make the Dulwich check a bit more robust.

> […]

> Ah, and before I forget: In order to run "make tests" I again had to
> apply the following patch:

> […]

Oops. I have an alias for `hg` defined so a fat-fingered `hg hg up` does what I meant. Turns out that leaked into the repository :)

[Uwe Brauer]

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

> On 2 Feb 2021, at 15.50, Uwe Brauer <o...@mat.ucm.es> wrote:
>>>>> "DVPC" == Dan Villiom Podlaski Christiansen <dan...@gmail.com> writes:

> I haven't heard from Manuel since before Christmas, I think; he's
> probably been busy. Anyway, I've rebased and pushed the topics.

So it is not in stable or default?

> As to the change itself, it seems like a bit of a hack to me, so I'd
> be reluctant to apply it as-is.

Hm, I only can say this: I used it since it was pushed and did not find
any problems so far, but I cannot judge what you said.

The feature seems quite important to me.

Regards

Uwe

[Dr Rainer Woitok]

Dan,

On Wednesday, 2021-02-03 15:57:27 +0100, you wrote:

> ...

> If Dulwich truly wasn't available, almost all of the tests would fail, and you wouldn't be able to interact with _any_ Git repository. So this is something internal to the test suite, and I'm not sure why those three tests happen to fail. I suspect it's something about the path or $PYTHON location that's going wrong.
>
> I'll try to make the Dulwich check a bit more robust.

Don't hesitate telling me how I can help hunting down the cause ... :-)

Sincerely,
Rainer

[Dan Villiom Podlaski Christiansen]

On 3 Feb 2021, at 16.04, Uwe Brauer <o...@mat.ucm.es> wrote:

>>>> "DVPC" == Dan Villiom Podlaski Christiansen <dan...@gmail.com> writes:
>
>> On 2 Feb 2021, at 15.50, Uwe Brauer <o...@mat.ucm.es> wrote:
>>>>>> "DVPC" == Dan Villiom Podlaski Christiansen <dan...@gmail.com> writes:
>
>> I haven't heard from Manuel since before Christmas, I think; he's
>> probably been busy. Anyway, I've rebased and pushed the topics.
>
> So it is not in stable or default?

At the moment, there's only one branch in the repository — default — and no, it isn't in it 🙂

>> As to the change itself, it seems like a bit of a hack to me, so I'd
>> be reluctant to apply it as-is.
>
> Hm, I only can say this: I used it since it was pushed and did not find
> any problems so far, but I cannot judge what you said.
>
> The feature seems quite important to me.

I can imagine that pushing named branches or topics is quite useful indeed, but that's not what the change does. It bolts on the ability to export… something. There's no motivation for it; nothing that explains the _why_ rather than the _how_.

So a good first step would be just elaborating on how you're relying on this. Either on this list, or in an issue describing the use case you're missing.

After all, this is open source; I'm not getting paid to do this. If you want something done, I'd encourage you to dig into the code and take a stab at fixing it! Or just file an issue 🙂

--

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

[Uwe Brauer]

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

> On 3 Feb 2021, at 16.04, Uwe Brauer <o...@mat.ucm.es> wrote:
>>>>> "DVPC" == Dan Villiom Podlaski Christiansen <dan...@gmail.com> writes:
>>
>>> On 2 Feb 2021, at 15.50, Uwe Brauer <o...@mat.ucm.es> wrote:
>>>>>>> "DVPC" == Dan Villiom Podlaski Christiansen <dan...@gmail.com> writes:
>>
>>> I haven't heard from Manuel since before Christmas, I think; he's
>>> probably been busy. Anyway, I've rebased and pushed the topics.
>>
>> So it is not in stable or default?

> At the moment, there's only one branch in the repository — default — and no, it isn't in it 🙂

Ok I was confused because you said you rebased and pushed.

>>> As to the change itself, it seems like a bit of a hack to me, so I'd
>>> be reluctant to apply it as-is.
>>
>> Hm, I only can say this: I used it since it was pushed and did not find
>> any problems so far, but I cannot judge what you said.
>>
>> The feature seems quite important to me.

> I can imagine that pushing named branches or topics is quite useful
> indeed, but that's not what the change does. It bolts on the ability
> to export… something. There's no motivation for it; nothing that
> explains the _why_ rather than the _how_.


> So a good first step would be just elaborating on how you're relying
> on this. Either on this list, or in an issue describing the use case
> you're missing.

Ok fair enough, some time ago I wrote some notes about that subject, let
me try to dig them out.

> After all, this is open source; I'm not getting paid to do this.

Right no offense intended :-[

> If you want something done, I'd encourage you to dig into the code and
> take a stab at fixing it! Or just file an issue 🙂

I just found it quite useful, I think named branches are still a bit
more standard than topics since they don't rely on the evolve extension,
but his hack can deal with both, but not at the same time.

As for improving that patch, I wish I could, but my python knowledge is
sketchy at best (I can barely understand numerical implementations
written in python instead of in Matlab), on my TODO list, but workload
and stuff......

Regards

Uwe

[Dan Villiom Podlaski Christiansen]

Could you perhaps try out this merge request?

https://foss.heptapod.net/mercurial/hg-git/-/merge_requests/87

[Uwe Brauer]

Hi Dan

I can imagine that pushing named branches or topics is quite useful indeed, but that's not what the change does. It bolts on the ability to export… something. There's no motivation for it; nothing that explains the why rather than the how.

So a good first step would be just elaborating on how you're relying on this. Either on this list, or in an issue describing the use case you're missing.

Till now I had barely time to elaborate it, now I did some testing over the weekend with Manuel's patch and here are my conclusions. In a nutshell:

1. quite useful if all users are using mercurial but use a repository say at Github in git.
2. Not that useful if you want to collaborate on Github with git users.

Here is the longer story

Regards

Uwe

1 The named branch patch for hg-git, what works and what not

First the right setup

1.1 Checkout the right changeset

 changeset:   1427:acc4280e2ab7
│  Branch:      default
│  Author:      Manuel Jacob <memanueljacob.de>
│  Date:        Sat, 01 Jun 2019 16:54:53 +0200
│  Topic:       export-additional-refs
│  Phase:       draft
│  Summary:     git_handler: add mechanism to specify revsets to be exported to Git refs according to a template
│

1.2 [git] Setting in .hgrc

# setting for named branches 
# tried out
export-additional-refs.named-branch-heads:revset   = head() and not  branch('re:\Adefault\Z')
# named branches should not have a prefix
export-additional-refs.named-branch-heads:template = refs/heads/{branch}
# Manuel Jacobs for pushing default to master: you have to  delete the bookmark master
export-additional-refs.default_as_master:revset    = head() and  branch('re:\Adefault\Z')
export-additional-refs.default_as_master:template  = refs/heads/master
use_namespaces = True

1.3 Works: All users use HG, but a git repository say at github

HG<–>GitHub<–>HG

The following works:

1. Named branches are conserved
2. No bookmark is needed for the master branch , in fact the default branch is pushed always to the git master branch, you even have to delete the master bookmark

1.4 What does not work: Interchange with a git user a GitHub repository

What works

1. Named branches are correctly pushed and converted to a git branch
2. However, when the git user checks out that (named) branch and commits, then
3. When pulling the corresponding changeset ends up on the default branch with a bookmark,
4. Rebasing (with or without evolve) does not help
5. However that changeset could be merged into the named branch, creating a somehow ugly graph.

In order to see the problem we perform a local simplified clone of a real git repository

1.4.1 the local cloned repositories

1. git clone git+ssh://oubgit.code.sf.net/p/matlab-emacs/src
2. mv src matlab-git
3. add to the git configuration file

     [receive]
             denyCurrentBranch = ignore

1. mkdir bare
2. cd bare
3. git clone ../matlab-git (to simplify the repository so that there is just the master branch)
4. Add to the git configuration file

     [receive]
             denyCurrentBranch = ignore

1. hg clone matlab-git matlab-hg
2. hg branch testbranch
3. edit and commit
   1. awk -i inplace 'BEGINFILE{print "f2021-04-17 Uwe Brauer <oubmat.ucm.es>* named branch"}{print}' ChangeLog
   2. hg ci -m "Add to the name branch"
4. hg book -d master
5. hg push
6. cd ../matlab-git
7. git checkout testbranch
8. edit and commit:
   1. awk -i inplace 'BEGINFILE{print "f2021-04-17 Uwe Brauer <oubmat.ucm.es>* git branch"}{print}' ChangeLog
   2. git add .
   3. git commit -m "Git: commit, tries to contribute to the named branch"
9. cd ../matlab-hg
10. ups: the new commit is not in the named branch but on the default branch with a bookmark, not good

       changeset:   492:2436d6505106
     │  Branch:      default
     │  tag:         default/testbranch
     │  tag:         tip
     │  bookmark:    testbranch
     │  Author:      Uwe Brauer <oubmat.ucm.es>
     │  Date:        Sun, 18 Apr 2021 17:34:55 +0200
     │  Phase:       draft
     │  Summary:     Git: commit, tries to contribute to the named branch
     │
     ◍  changeset:   491:a6dce40fa191
     │  Branch:      testbranch
     │  Author:      Uwe Brauer <oubmat.ucm.es>
     │  Date:        Sun, 18 Apr 2021 17:34:26 +0200
     │  Phase:       draft
     │  Summary:     Add to the name branch

1. so we use rebase, for example
2. hg rebase -b 492 -d 491
3. hg push: pushes fails
   1. with evolve

          pushing to /home/oub/HGTest/HG-Git-Test-Patch-Named/Matlab-new/bare/matlab-git
          searching for changes
          abort: pushing refs/heads/testbranch overwrites c783a9ea0e13

1. without evolve
   1. hg strip 493
   2. hg rebase -b 492 -d 491

           pushing to /home/oub/HGTest/HG-Git-Test-Patch-Named/Matlab-new/bare/matlab-git
           searching for changes
           abort: unknown revision '2436d6505106ff54f59c8a2fa0a7f73a8b70070a'!

1. it remains to do a merge, that works
2. hg strip 493
3. hg merge -4 492

        changeset:   493:f02743c68c08
      │╲   Branch:      testbranch
      │ │  tag:         tip
      │ │  Author:      Uwe Brauer <oubmat.ucm.es>
      │ │  Date:        Sun, 18 Apr 2021 17:42:54 +0200
      │ │  Phase:       draft
      │ │  Summary:     Silly merge
      │ │
      │ ○  changeset:   492:ece53f11267b
      │╱   Branch:      default
      │    tag:         default/testbranch
      │    bookmark:    testbranch
      │    Author:      Uwe Brauer <oubmat.ucm.es>
      │    Date:        Sun, 18 Apr 2021 17:42:33 +0200
      │    Phase:       draft
      │    Summary:     Git: commit, tries to contribute to the named branch

1. hg push works now

      *commit 4105340764307a844653cee956e33b7ed7bd2eb1 (HEAD -> testbranch)
      |\  Merge: e72a3d4 20117e9
      | | Author: Uwe Brauer <oubmat.ucm.es>
      | | Date:   Sun Apr 18 17:42:54 2021 +0200
      | |
      | |     Silly merge
      | |
      | |     --HG--
      | |     branch : testbranch
      | |
      | * commit 20117e94a6f7204086b33837c4f9e44719ff187c (master)
      |/  Author: Uwe Brauer <o...@mat.ucm.es>
      |   Date:   Sun Apr 18 17:42:33 2021 +0200
      |
      |       Git: commit, tries to contribute to the named branch
      |