Bless fork as official mainline

[infinity0]

Hi, I'm looking to update this package in Debian, which is currently using @fingolfin's fork. Currently there are various critical issues with it including lack of hg 4.0 support.

This seems to be fixed in a different fork by @mnauw which also seems to be much more active. Would you mind editing the README of this project to point to that fork instead, thereby making it "official" so that I can feel less guilty about updating the package in Debian? It would also be good to close all bug reports here and redirect them to the new repo.

The same goes to @fingolfin for his fork, which seems no longer actively maintained - can you please point people to @mnauw's fork?

[pirat89]

Same for Fedora. I am watching for @mnauw's fork too.

[apjanke]

Same for Mac Homebrew. I'm curious as to what the status of the two forks are at this point.

[devinrhode2]

@mnauw's fork works, again!

[felipec]

@infinity0 @pirat89 @apjanke I lost motivation on the project, and it was working perfectly.

At the time not many people were interested in contributing, only using it, it seems the situation has changed, but we shall see.

I got motivated again and fixed all the compatibility issues. It should work correctly with Mercurial from 2.0 to 5.0. The new release v0.4 should just work.

Unfortunately I also found issues with Git core, and hg-git which I use for testing purposes. I sent patches to both of those projects, but we shall see.

I always had issues with fingolfin, I don't see any particular reason to look at that code.

However, I have actually worked with @mnauw before, and I do not doubt there is useful code in his fork. However, as of now I have not yet looked into it.

It would be nice if somebody listed the difference between my latest release (v0.4) and @mnauw's fork, and if there's anything in particular needed from my version.

[felipec]

I actually did look into this some time ago and I didn't find anything that @mnauw's fork provides that is useful for most people. The only potentially useful feature would be shared marks, but that would very easily corrupt the marks, which presumably why @mnauw's fork requires infrastructure to fix the marks.