import git branches as topics?

[Uwe Brauer]

Hi

While it is possible to use named branches, on a remote git server such
as github, it only makes sense if every users uses mercurial and the
hg-git extension.

However most the git repositories I use, are used by git users.

So far git branches are imported into mercurial as topological heads on
the default branch with bookmarks.

Is there any possibility to import them using topics (with the evolve)
extension.

Regards

Uwe Brauer

[Dan Villiom Podlaski Christiansen]

Short answer: no, sorry.

Long answer:

From a technical perspective, topics are the same as branches but in a different namespace. Like branches, the “topic” of a changeset is part of it and embedded in its extra metadata. The changeset is identified by its hash, which is calculated based on its contents, including that extra metadata. So just as with its branch, you cannot alter the topic of a changeset without creating a new and different changeset. The reason you don't notice this is that the topic extension builds on topic of history evolution, and transparently manages that — and disregards the topic of any published changeset.

So, if you were to implement this, a reasonable starting point would be to add support for pulling Git branches as Mercurial branches. Most of the logic should apply to topics as well.

Now, what's the challenge with branches/topics? With both, converting from a Git commit into a Mercurial equivalent, would require knowing _into_ which branch or topic that should be. Similarly, any given Git commit could belong to any number of branches or topics.

The reason for converting Git branches into bookmarks is that they map rather well to each other — by design. Converting them into proper branches or even topics would indeed be much nicer, but it's also significantly harder. Personally, I'd rather improve the bookmarks workflow first.

(Some obvious improvements include pruning stale remotes[1] and rebase detection.[2] The former has a PR just waiting on review.)

Still, if you'd like to see this, I'd encourage you to try implementing it. Perhaps it's not as difficult as I expect 🙂


[1] https://foss.heptapod.net/mercurial/hg-git/-/merge_requests/96
[2] https://foss.heptapod.net/mercurial/hg-git/-/issues/353

--

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

[Uwe Brauer]

> On 7 May 2021, at 17.31, Uwe Brauer <o...@mat.ucm.es> wrote:

> Short answer: no, sorry.

> Long answer:

> From a technical perspective, topics are the same as branches but in a
> different namespace. Like branches, the “topic” of a changeset is part
> of it and embedded in its extra metadata. The changeset is identified
> by its hash, which is calculated based on its contents, including that
> extra metadata. So just as with its branch, you cannot alter the topic
> of a changeset without creating a new and different changeset. The
> reason you don't notice this is that the topic extension builds on
> topic of history evolution, and transparently manages that — and
> disregards the topic of any published changeset.

Well I also wanted to ask about named branches (which I use more, but I
though topics are more suitable for short lived branches and also more
hm sexy)

> So, if you were to implement this, a reasonable starting point would
> be to add support for pulling Git branches as Mercurial branches. Most
> of the logic should apply to topics as well.

> Now, what's the challenge with branches/topics? With both, converting
> from a Git commit into a Mercurial equivalent, would require knowing
> _into_ which branch or topic that should be. Similarly, any given Git
> commit could belong to any number of branches or topics.

> The reason for converting Git branches into bookmarks is that they map
> rather well to each other — by design. Converting them into proper
> branches or even topics would indeed be much nicer, but it's also
> significantly harder. Personally, I'd rather improve the bookmarks
> workflow first.

Hm, I thought creating a branch in git always create a head (in
mercurial terminology), while creating a bookmark in HG not necessarily
does it.

Be it as it may, from a purely user point of view,
a repository with bookmarks (cloned from git) looks like this

changeset: 6:94feac535ac7
│ Branch: default
│ tag: tip
│ bookmark: master
│ Author: Uwe Brauer <o...@mat.ucm.es>
│ Date: Sat, 08 May 2021 10:40:56 +0200
│ Phase: draft
│ Summary: Fifth
│
│ ○ changeset: 5:ee142658daaa
│ │ Branch: default
│ │ bookmark: feature
│ │ Author: Uwe Brauer <o...@mat.ucm.es>
│ │ Date: Sat, 08 May 2021 10:40:56 +0200
│ │ Phase: draft
│ │ Summary: Second in branch
│ │
│ ○ changeset: 4:3e173b96e671
│ │ Branch: default
│ │ Author: Uwe Brauer <o...@mat.ucm.es>
│ │ Date: Sat, 08 May 2021 10:40:55 +0200
│ │ Phase: draft
│ │ Summary: First in branch
│ │
○ │ changeset: 3:913fe1a11c00

A repository created with HG and named branches would be of this form.

changeset: 6:78fcac51de7b
│ Branch: default
│ tag: tip
│ Author: Uwe Brauer <o...@mat.ucm.es>
│ Date: Sat, 08 May 2021 10:37:30 +0200
│ Phase: draft
│ Summary: Fifth
│
│ ○ changeset: 5:67ba3f39fcb2
│ │ Branch: feature
│ │ Author: Uwe Brauer <o...@mat.ucm.es>
│ │ Date: Sat, 08 May 2021 10:37:29 +0200
│ │ Phase: draft
│ │ Summary: Second in branch
│ │
│ ○ changeset: 4:5d3ba31ee3b2
│ │ Branch: feature
│ │ Author: Uwe Brauer <o...@mat.ucm.es>
│ │ Date: Sat, 08 May 2021 10:37:29 +0200
│ │ Phase: draft
│ │ Summary: First in branch
│ │
○ │ changeset: 3:562767f9dce7

So it contains the nice tag «feature» indicating the branch from the
beginning to the end, which is so helpful.

Now it is possible to «transform» the «branch/topological» head with the
bookmark «feature» into a real named branch using evolve:


hg book -d feature
hg up 4
hg branch feature
hg amend
hg evolve

Which results in

○ changeset: 8:90c029ba68b6
│ Branch: feature
│ tag: tip
│ Author: Uwe Brauer <o...@mat.ucm.es>
│ Date: Sat, 08 May 2021 10:42:43 +0200
│ Phase: draft
│ Summary: Second in branch
│
◍ changeset: 7:d33c3cb4320b
│ Branch: feature
│ Author: Uwe Brauer <o...@mat.ucm.es>
│ Date: Sat, 08 May 2021 10:42:43 +0200
│ Phase: draft
│ Summary: First in branch
│
│ ○ changeset: 6:0a988c629ea1
│ │ Branch: default
│ │ bookmark: master
│ │ Author: Uwe Brauer <o...@mat.ucm.es>
│ │ Date: Sat, 08 May 2021 10:42:43 +0200
│ │ Phase: draft
│ │ Summary: Fifth
│ │
│ ○ changeset: 3:a6d02fd3ddf9
│╱ Branch: default
│ Author: Uwe Brauer <o...@mat.ucm.es>
│ Date: Sat, 08 May 2021 10:42:42 +0200
│ Phase: draft
│ Summary: Fourth

Ok the hashes have changed and the old changesets are now marked as
obsolete. If would do this will a git repository I cloned, and
«transformed» the bookmark like this, it would screw things up when
trying to push.

So the question is:

could such an operation be done, so that the new
changesets, will obtain the original corresponding git hashes????

That would be a first step forward, so one could manually transform
bookmarks into named branch.

I presume it is not possible since otherwise it would have already be
implemented.

Regards

Uwe

[Dan Villiom Podlaski Christiansen]

On 8 May 2021, at 10.56, Uwe Brauer <o...@mat.ucm.es> wrote:

>> On 7 May 2021, at 17.31, Uwe Brauer <o...@mat.ucm.es> wrote:
>
>> Short answer: no, sorry.
>
>> Long answer:
>
>> From a technical perspective, topics are the same as branches but in a
>> different namespace. Like branches, the “topic” of a changeset is part
>> of it and embedded in its extra metadata. The changeset is identified
>> by its hash, which is calculated based on its contents, including that
>> extra metadata. So just as with its branch, you cannot alter the topic
>> of a changeset without creating a new and different changeset. The
>> reason you don't notice this is that the topic extension builds on
>> topic of history evolution, and transparently manages that — and
>> disregards the topic of any published changeset.
>
> Well I also wanted to ask about named branches (which I use more, but I
> though topics are more suitable for short lived branches and also more
> hm sexy)

Yeah, topics would be nice, but given that it's an external dependency, I think addressing branches would be easier.

>> So, if you were to implement this, a reasonable starting point would
>> be to add support for pulling Git branches as Mercurial branches. Most
>> of the logic should apply to topics as well.
>
>> Now, what's the challenge with branches/topics? With both, converting
>> from a Git commit into a Mercurial equivalent, would require knowing
>> _into_ which branch or topic that should be. Similarly, any given Git
>> commit could belong to any number of branches or topics.
>
>> The reason for converting Git branches into bookmarks is that they map
>> rather well to each other — by design. Converting them into proper
>> branches or even topics would indeed be much nicer, but it's also
>> significantly harder. Personally, I'd rather improve the bookmarks
>> workflow first.
>
> Hm, I thought creating a branch in git always create a head (in
> mercurial terminology), while creating a bookmark in HG not necessarily
> does it.

I don't know if you're familiar with Subversion, but one interesting aspect of it is that it doesn't actually support neither branches nor tags. It's just a versioned file system with some conventions added on top.

To some extent Git is similar, but adds a bit of UI porcelain on top. What Git calls branches are just loose pointers to commits that move around, and so are tags; it's just that moving them is harder.

That's why hg-git currently converts Git branches into bookmarks and Git tags into something like local tags. Essentially, it's the easy thing to do. Mercurial branches are embedded in the commit message, as seen here:

https://foss.heptapod.net/mercurial/hg-git/-/commit/1e916b2cfa96d9995bdf3d43ffc188df704539c1

(Heptapod uses hg-git under the hood for most repositories.)

One major advantage to this is bidirectionality. This means that you can push a repository from Mercurial to Git, clone it using Mercurial, and push back into the first repository safely. This holds for _most_ commits, but is easily broken by stuff like graft.

A branch or topic mode would most definitely break bidirectionality. I don't see that as a major issue, though. You could work around that by transferring the Git state — as shown in https://foss.heptapod.net/mercurial/hg-git/-/merge_requests/73, for example.

You would likely need to do a force push; that's what Git requires you to do when pushing something to a branch that's not a direct descendent of the current commit.

> So the question is:
>
> could such an operation be done, so that the new
> changesets, will obtain the original corresponding git hashes????
>
> That would be a first step forward, so one could manually transform
> bookmarks into named branch.

Yes and no. First, you have to understand how hg-git obtains the “corresponding git hash”. At the fundamental level, it's determined by a file called `git-mapfile` within the `.hg` directory. This is just a file listing Mercurial and Git commit hashes.

At its core, hg-git has two commands for transferring data between Mercurial and Git: `gexport` command converts Mercurial commits to Git, and notes the result in the map. Similarly, `gimport` looks at the local Git repository, and converts commits to Mercurial, also noting them in the map. At a conceptual level, a pull means fetching changes from a Git remote into the local Git repository, and then running gimport. Likewise, pushing involves exporting commits and then sending them to the remote.

Pushing from branches instead bookmarks is relatively easy. I made a quick attempt at doing so some time ago; I just updated it and posted a draft merge request.[1]

Pulling is somewhat more involved. A Git commit could result in multiple Mercurial commits, and that's a built-in assumption in the code at the moment. If you look at the code you'll see that `import_git_objects()` just iterates over the incoming commits and calls `import_git_commit()` for each of them. Then there's the issue of tracking that: Where should future commits then go?

[1] https://foss.heptapod.net/mercurial/hg-git/-/merge_requests/101

> I presume it is not possible since otherwise it would have already be
> implemented.

Well, anything is possible, it's just a question of effort 🙂 I wouldn't call adding _full_ support for branches or topics impossible; it's just not a trivial undertaking. I expect there'd be many small issues to iron out, but it should be doable.

[Uwe Brauer]

> On 8 May 2021, at 10.56, Uwe Brauer <o...@mat.ucm.es> wrote:




> I don't know if you're familiar with Subversion, but one interesting
> aspect of it is that it doesn't actually support neither branches nor
> tags. It's just a versioned file system with some conventions added on
> top.

Well I started with, hm, RCS, had to use then CVS (which was terrible)
and then someone recommended me subversion, because «it is very
intuitive» (most people seem to consider server based models more
intuitive.
When I read the documentation, what a «branch» is supposed to be and how
a merge should be performed, I thought this is simply insane and turned
my attention to git and mercurial (this was at the time, when GNU emacs
discussed with what to replace bazzarr (unfortunately the vote was in
favour of git because it was more popular, which makes it a self
fulfilling prophec)). I couldn't really understand the git graph (which
change set belongs to which branch) so I choose mercurial.

> To some extent Git is similar, but adds a bit of UI porcelain on top.
> What Git calls branches are just loose pointers to commits that move
> around, and so are tags; it's just that moving them is harder.

> That's why hg-git currently converts Git branches into bookmarks and
> Git tags into something like local tags. Essentially, it's the easy
> thing to do. Mercurial branches are embedded in the commit message, as
> seen here:

> https://foss.heptapod.net/mercurial/hg-git/-/commit/1e916b2cfa96d9995bdf3d43ffc188df704539c1

> (Heptapod uses hg-git under the hood for most repositories.)

A moment, I used heptapod is based on mercurial and even encourage the
use topics, what do I miss here.

> One major advantage to this is bidirectionality. This means that you
> can push a repository from Mercurial to Git, clone it using Mercurial,
> and push back into the first repository safely. This holds for _most_
> commits, but is easily broken by stuff like graft.

> A branch or topic mode would most definitely break bidirectionality. I
> don't see that as a major issue, though. You could work around that by
> transferring the Git state — as shown in
> https://foss.heptapod.net/mercurial/hg-git/-/merge_requests/73, for
> example.

> You would likely need to do a force push; that's what Git requires you
> to do when pushing something to a branch that's not a direct
> descendent of the current commit.

Well yes that is what I mean with screw things up a forced push would
make the git users scream.

> Yes and no. First, you have to understand how hg-git obtains the
> “corresponding git hash”. At the fundamental level, it's determined by
> a file called `git-mapfile` within the `.hg` directory. This is just a
> file listing Mercurial and Git commit hashes.

> At its core, hg-git has two commands for transferring data between
> Mercurial and Git: `gexport` command converts Mercurial commits to
> Git, and notes the result in the map. Similarly, `gimport` looks at
> the local Git repository, and converts commits to Mercurial, also
> noting them in the map. At a conceptual level, a pull means fetching
> changes from a Git remote into the local Git repository, and then
> running gimport. Likewise, pushing involves exporting commits and then
> sending them to the remote.

> Pushing from branches instead bookmarks is relatively easy. I made a
> quick attempt at doing so some time ago; I just updated it and posted
> a draft merge request.[1]

Hm is this somehow connected to Manual Jacob's patch I mentioned some
weeks ago.


◍ changeset: 1427:acc4280e2ab7
│ Branch: default
│ Author: Manuel Jacob <m...@manueljacob.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
│
○ changeset: 1426:3ad09bbcbe3e
│ Branch: default
│ Author: Manuel Jacob <m...@manueljacob.de>
│ Date: Sat, 01 Jun 2019 16:55:10 +0200
│ Topic: same-ref-for-multiple-changesets
│ Phase: draft
│ Summary: git_handler: make sure that the same ref is not used for multiple changesets



His patch sort of works if everybody is using mercurial and pushes and
pulls to a git repository

I am one of the emacs-matlab maintainers and we switched from CVS to a
more modern VC, I wanted mercurial but was voted down by the others,
shrug, so use the hg-git plugin, I tried to use his patch but because
pulling results in new heads this workflow is not very practical

> Pulling is somewhat more involved. A Git commit could result in
> multiple Mercurial commits, and that's a built-in assumption in the
> code at the moment. If you look at the code you'll see that
> `import_git_objects()` just iterates over the incoming commits and
> calls `import_git_commit()` for each of them. Then there's the issue
> of tracking that: Where should future commits then go?

> [1] https://foss.heptapod.net/mercurial/hg-git/-/merge_requests/101

Thanks for pointing that out to me.

[Dan Villiom Podlaski Christiansen]

On 8 May 2021, at 16.03, Uwe Brauer <o...@mat.ucm.es> wrote:
>
> Well I started with, hm, RCS, had to use then CVS (which was terrible)
> and then someone recommended me subversion, because «it is very
> intuitive» (most people seem to consider server based models more
> intuitive.
> When I read the documentation, what a «branch» is supposed to be and how
> a merge should be performed, I thought this is simply insane and turned
> my attention to git and mercurial (this was at the time, when GNU emacs
> discussed with what to replace bazzarr (unfortunately the vote was in
> favour of git because it was more popular, which makes it a self
> fulfilling prophec)). I couldn't really understand the git graph (which
> change set belongs to which branch) so I choose mercurial.

Ironically, I got started with Mercurial in a somewhat similar fashion: I was tracking Emacs development with Bazaar, and ended up with a corrupt repository. I looked for a different mirror, and found Mercurial 🙂

>> To some extent Git is similar, but adds a bit of UI porcelain on top.
>> What Git calls branches are just loose pointers to commits that move
>> around, and so are tags; it's just that moving them is harder.
>
>> That's why hg-git currently converts Git branches into bookmarks and
>> Git tags into something like local tags. Essentially, it's the easy
>> thing to do. Mercurial branches are embedded in the commit message, as
>> seen here:
>
>> https://foss.heptapod.net/mercurial/hg-git/-/commit/1e916b2cfa96d9995bdf3d43ffc188df704539c1
>
>> (Heptapod uses hg-git under the hood for most repositories.)
>
> A moment, I used heptapod is based on mercurial and even encourage the
> use topics, what do I miss here.

That was just an example to show how hg-git embeds the branch metadata into Git commits.

(Heptapod is a fork of GitLab where they added Mercurial support. To begin with, they used hg-git to aid the implementation, and most repositories still rely on that.)

I added some support for pulling new commits in branches to that MR. It's very untested, but it just might work 🙂

> I am one of the emacs-matlab maintainers and we switched from CVS to a
> more modern VC, I wanted mercurial but was voted down by the others,
> shrug, so use the hg-git plugin, I tried to use his patch but because
> pulling results in new heads this workflow is not very practical
>
>
>> Pulling is somewhat more involved. A Git commit could result in
>> multiple Mercurial commits, and that's a built-in assumption in the
>> code at the moment. If you look at the code you'll see that
>> `import_git_objects()` just iterates over the incoming commits and
>> calls `import_git_commit()` for each of them. Then there's the issue
>> of tracking that: Where should future commits then go?
>
>> [1] https://foss.heptapod.net/mercurial/hg-git/-/merge_requests/101
>
>
> Thanks for pointing that out to me.
>
>> Well, anything is possible, it's just a question of effort 🙂 I
>> wouldn't call adding _full_ support for branches or topics impossible;
>> it's just not a trivial undertaking. I expect there'd be many small
>> issues to iron out, but it should be doable.

[Uwe Brauer]

> On 8 May 2021, at 16.03, Uwe Brauer <o...@mat.ucm.es> wrote:

> Ironically, I got started with Mercurial in a somewhat similar
> fashion: I was tracking Emacs development with Bazaar, and ended up
> with a corrupt repository. I looked for a different mirror, and found
> Mercurial 🙂

Well I forgot to add that I was involved in the xemacs team (but just
maintaining some package) and they switched from CVS to mercurial, it
turned out however that most of the developer were die hard git fans and
dis-encouraged the use of named branch.

> That was just an example to show how hg-git embeds the branch metadata into Git commits.

> (Heptapod is a fork of GitLab where they added Mercurial support. To
> begin with, they used hg-git to aid the implementation, and most
> repositories still rely on that.)

Right, I know that, but I still wounder how they can then topics make to
work without a native mercurial support.

> I added some support for pulling new commits in branches to that MR.
> It's very untested, but it just might work 🙂

Oh I would be extremely in testing that (maybe for the moment being on a
sandbox)
I am not that acquainted with the famous (infamous [1]) merge request.

Where precisely can I find (clone) the repository with these
experimental features?

Uwe

Footnotes:
[1] https://gregoryszorc.com/blog/2020/01/07/problems-with-pull-requests-and-how-to-fix-them/

[Dan Villiom Podlaski Christiansen]

> On 8 May 2021, at 21.41, Uwe Brauer <o...@mat.ucm.es> wrote:
>
>
>> On 8 May 2021, at 16.03, Uwe Brauer <o...@mat.ucm.es> wrote:
>
>> Ironically, I got started with Mercurial in a somewhat similar
>> fashion: I was tracking Emacs development with Bazaar, and ended up
>> with a corrupt repository. I looked for a different mirror, and found
>> Mercurial 🙂
>
> Well I forgot to add that I was involved in the xemacs team (but just
> maintaining some package) and they switched from CVS to mercurial, it
> turned out however that most of the developer were die hard git fans and
> dis-encouraged the use of named branch.
>
>> That was just an example to show how hg-git embeds the branch metadata into Git commits.
>
>> (Heptapod is a fork of GitLab where they added Mercurial support. To
>> begin with, they used hg-git to aid the implementation, and most
>> repositories still rely on that.)
>
> Right, I know that, but I still wounder how they can then topics make to
> work without a native mercurial support.

From my understanding, the Git repository is/was mostly for integrating with all the GitLab infrastructure. Mercurial still interacts with a proper repository.

>> I added some support for pulling new commits in branches to that MR.
>> It's very untested, but it just might work 🙂
>
> Oh I would be extremely in testing that (maybe for the moment being on a
> sandbox)
> I am not that acquainted with the famous (infamous [1]) merge request.
>
> Where precisely can I find (clone) the repository with these
> experimental features?

The MR is based on the `branches-and-stuff` topic in the main hg-git repository:

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

I wouldn't use it for anything serious; it's almost entirely untested.

[Uwe Brauer]

> From my understanding, the Git repository is/was mostly for
> integrating with all the GitLab infrastructure. Mercurial still
> interacts with a proper repository.

> The MR is based on the `branches-and-stuff` topic in the main hg-git repository:

> https://foss.heptapod.net/mercurial/hg-git

Well I have cloned
https://dev.heptapod.net/mercurial/hg-git

Is this just a mirror or something entirely different?

> I wouldn't use it for anything serious; it's almost entirely untested.

Right, is there any configuration necessary?
For Manuel Jacob's topic (branch) it was necessary to have something
like this

export-additional-refs.named-branch-heads:revset = head() and branch('re:\Adefault\Z')
export-additional-refs.named-branch-heads:template = refs/heads/{branch}
# Manuel Jacobs config for master: but 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

Do yours need a similar setting?

[Uwe Brauer]

> From my understanding, the Git repository is/was mostly for
> integrating with all the GitLab infrastructure. Mercurial still
> interacts with a proper repository.

> The MR is based on the `branches-and-stuff` topic in the main hg-git repository:

> https://foss.heptapod.net/mercurial/hg-git

> I wouldn't use it for anything serious; it's almost entirely untested.

Hm I am still running hg 5.2rc0+20200125
because of certain old extensions like Artemis that is not running under
more recent mercurial version.

Be it as it may to be on the save side I cloned the directory again, and
updated to that branch. I changed by setting in my .hgrc file from

## updated to Manuel Jacob's patch
#hggit = /home/oub/ALLES/src/hg-git-heptapod/hggit

# your branch
hggit = /home/oub/ALLES/src/hg-git-hepta/hggit

However I obtain ** failed to import extension hggit from /home/oub/ALLES/src/hg-git-hepta/hggit: future feature generator_stop is not defined (__init__.py, line 122)

What is the minimum hg version I need for that to work?

[Dan Villiom Podlaski Christiansen]

On 9 May 2021, at 08.41, Uwe Brauer <o...@mat.ucm.es> wrote:

> Well I have cloned
> https://dev.heptapod.net/mercurial/hg-git
>
> Is this just a mirror or something entirely different?

$ host dev.heptapod.net
dev.heptapod.net is an alias for foss.heptapod.net.

I think they're the same 🙂

>> I wouldn't use it for anything serious; it's almost entirely untested.
>

> Right, is there any configuration necessary?
> For Manuel Jacob's topic (branch) it was necessary to have something
> like this
>
> export-additional-refs.named-branch-heads:revset = head() and branch('re:\Adefault\Z')
> export-additional-refs.named-branch-heads:template = refs/heads/{branch}
> # Manuel Jacobs config for master: but 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
>
> Do yours need a similar setting?

No, you should just need:

[hggit]
mode = branches

There's no further configuration at the moment, although I understand some users would like that.

On 9 May 2021, at 16.17, Uwe Brauer <o...@mat.ucm.es> wrote:

> Hm I am still running hg 5.2rc0+20200125
> because of certain old extensions like Artemis that is not running under
> more recent mercurial version.
>
> Be it as it may to be on the save side I cloned the directory again, and
> updated to that branch. I changed by setting in my .hgrc file from
>
> ## updated to Manuel Jacob's patch
> #hggit = /home/oub/ALLES/src/hg-git-heptapod/hggit
>
> # your branch
> hggit = /home/oub/ALLES/src/hg-git-hepta/hggit
>
> However I obtain ** failed to import extension hggit from /home/oub/ALLES/src/hg-git-hepta/hggit: future feature generator_stop is not defined (__init__.py, line 122)
>
> What is the minimum hg version I need for that to work?

Mercurial 5.2 should work, but the default branch only supports Python 3, which is the cause of that error.

[Uwe Brauer]

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

> On 9 May 2021, at 08.41, Uwe Brauer <o...@mat.ucm.es> wrote:

>> Well I have cloned
>> https://dev.heptapod.net/mercurial/hg-git
>>
>> Is this just a mirror or something entirely different?

> $ host dev.heptapod.net
> dev.heptapod.net is an alias for foss.heptapod.net.

> I think they're the same 🙂

>>> I wouldn't use it for anything serious; it's almost entirely untested.
>>
>> Right, is there any configuration necessary?
>> For Manuel Jacob's topic (branch) it was necessary to have something
>> like this
>>
>> export-additional-refs.named-branch-heads:revset = head() and branch('re:\Adefault\Z')
>> export-additional-refs.named-branch-heads:template = refs/heads/{branch}
>> # Manuel Jacobs config for master: but 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
>>
>> Do yours need a similar setting?

> No, you should just need:

> [hggit]
> mode = branches

Aha [hggit] not [git] as for Manuel's patch

> Mercurial 5.2 should work, but the default branch only supports Python
> 3, which is the cause of that error.

I see, I am still on Ubuntu 16.04 and I cannot upgrade till the course
finshes, however Ubuntu 16.04 ships only python 3.5 and this version is
not supported while 2.7 still is. I tried upgrading python in Ubuntu
16.04 but then the matlab python module stopped working.

I can however try it on the Mac I have access to.

[Pierre Augier]

Can't you install miniconda on Ubuntu 16.04 ?

If yes, you can run

conda activate base

pip install conda-app

conda-app install mercurial

This creates a conda virtualenv called _env_mercurial with mercurial, evolve and hg-git

You can update to any hg-git version by activating the environment:

conda activate _env_mercurial

and then just use `pip install -e .` in your special hg-git root directory.

--
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/87im3qqwiy.fsf%40mat.ucm.es.

[Uwe Brauer]

>>> "PA" == Pierre Augier <pierre...@ens-lyon.org> writes:

> Can't you install miniconda on Ubuntu 16.04 ?
> If yes, you can run

I could try, but how would it interfere with the mercurial version I installed

1. Compiling mercurial (make deb) with python 2.7

2. And then I install it with dpkg


> conda activate bas

> pip install conda-app
> conda-app install mercurial

> This creates a conda virtualenv called _env_mercurial with mercurial,
> evolve and hg-git

> You can update to any hg-git version by activating the environment:

> conda activate _env_mercurial

> and then just use `pip install -e .` in your special hg-git root directory.

I will give it a try maybe it at the weekend, or I try via fink, a
mercurial version that is compiled with either 3.6, 3.7 o 3.8 (in that
respect fink is very good since it provides a lot of backward
compatible pkgs).

[Dan Villiom Podlaski Christiansen]

On 10 May 2021, at 20.22, Uwe Brauer <o...@mat.ucm.es> wrote:

>> [hggit]
>> mode = branches
>
> Aha [hggit] not [git] as for Manuel's patch

Yeah, which to use which isn't terribly well-defined, but figured this was more control-of-hggit than strictly related to git.

>> Mercurial 5.2 should work, but the default branch only supports Python
>> 3, which is the cause of that error.
>
> I see, I am still on Ubuntu 16.04 and I cannot upgrade till the course
> finshes, however Ubuntu 16.04 ships only python 3.5 and this version is
> not supported while 2.7 still is. I tried upgrading python in Ubuntu
> 16.04 but then the matlab python module stopped working.
>
> I can however try it on the Mac I have access to.

Unfortunately, both Python 3.5 and Python 2.7 are end-of-life at this point — at least from the CPython maintainers. Python 3.5 still works with hg-git default, though, but that's more a happy accident than anything else.

If you want newer/other versions of Python on Ubuntu, the easiest approach is to use the deadsnakes PPA to install alternate versions of Python:

https://launchpad.net/~deadsnakes/+archive/ubuntu/ppa

It shouldn't cause any problems, as they merely exist in addition to Ubuntu's standard packages. To try out default on Ubuntu, you could either use 3.5 until it breaks, or install Python 3.9 from the that PPA, and then install Mercurial into a venv.

--

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