Mercurial support

[flibustenet]

Is this fork going to support Mercurial if of course someone can work on this ?

[thibaultmeyer]

I think it could be a good idea to give choice between Git or Mercurial when a repository is created. But I'm not sure Gitea have, currently, the necessary abstraction level to allow easily a new backend (Git or Mercurial) depending of the acceded repository.

Maybe when the "git" version will be stable and production ready...

For now, you can probably have a look for these alternatives who can work with both Git and Mercurial:

• Kallithea
• RhodeCode Community Edition

[joubertredrat]

SCM Manager supports mercurial too.

PS: Pesonally I prefer Fossil instead Mercurial.

[tboerger]

I think it can be a big plus for gitea to support mercurial and bazaar, but the name of the project will be irritating and we need lots of abstractions

[joubertredrat]

@tboerger sound be good?

"GMBFitea: Git, Mercurial, Bazaar, Fossil, All with a cup of tea". And true, will be necessary a lot of abstractions and see if golang support mercurial and bazaar API rerefence.

[tboerger]

We are also wrapping just the git cli, so go bindings are not a hard requirement :)

[lunny]

In a short term, this will not be consider I think.

[strk]

I also think this is outside the scope of Gitea

[thibaultmeyer]

The git and mercurial controls have practically the same behaviors. By example, the client SmartGit have the same UI for Mercurial and Git repos. It could make sens to become compatible with Mercurial.

[stevenroose]

It's even out of the scope of the name :D It's always good to have the choice, but I think it's more important to have a solid piece of software before adding non-core features...

[petrus-v]

A bit of reading regarding Mercurial support on gitlab a POC was done to show that git/mercurial basic workflow are very closed.

[Crystal-Lilith]

Hello everyone, i am quite curious if hg support will eventually be implemented, do you think that it will be worth putting the effort into making it happen?

[clarfonthey]

I also want to voice support for allowing multiple VCS types. Honestly, there are still lots of systems out there that use VCS other than git and allowing users to mirror those repos without converting them to git would be great. IMHO, the best thing would be to abstract the git logic so that ultimately people could develop extensions for different VCS, that way even if someone wanted to use gitea with e.g. CVS they could.

[VickyRampin]

Also wanted to chime in with my support for multiple VCS types. The Hg and SVN folks are kind of being left high and dry by other hosting platforms, and Gitea would have a great competitive advantage if it was to support multiple VCS's, especially with the ability to self-host (particularly important for my communities, in academia).

[zeripath]

git-as-svn should still work with Gitea.

[clarfonthey]

As I said, converting to git isn't really support, it's a workaround. The conversion isn't lossless, and it doesn't enable bidirectional operation, just unidirectional.

[zeripath]

@clarfon I meant:

https://github.com/bozaro/git-as-svn

Which does allow bidrectional operation.

[Qix-]

If for nothing else, being able to mirror murcurial repositories would be highly beneficial, even if they are "read only" from a git standpoint.

[techknowlogick]

Closing this as we are volunteers and we likely don't currently have the resources to do this. A lot of our code assumes git as VCS, and would take a large amount of effort to add another one. This isn't to say we wouldn't add HG support, but it would need someone to sponsor development and reviewers as large PRs (which this would need), take a lot of effort not just to make but review as well. It would also need coordination with maintainers so that perhaps PRs are split up into multiple PRs instead of just one big one, and to discuss approach prior to getting started.

[clarfonthey]

That's super fair. Hopefully at some point there will be enough interest and support for it, but for now it's extremely understandable that this isn't a priority.