gitea is now officially a separate application from gogs - changes from macaroni to chi

Gogs git project and repository manager marked the before and after in git management, but due to its conservative development line (less stupid commits for features), was born a parallel called gitea, this is no longer its shadow, not using macarron as framework, one of the base projects of the gogs architecture.

 

 Officially announced in gitea release 1.14 and developed in pull rquest # 14293 the gitea developers (who are always so bored that they add more stuff than gitlab itself to their gitlab) changed the macarron framework to the chi framework.

For those more knowledgeable in web development about golang, refer to these comparisons: https://github.com/diyan/go-web-framework-comparison#reviewed-libraries-and-frameworks

This totally separates gitea (which was already being fatter in features and options than gogs, even in configurations) from its parent gogs shadow, which is much more conservative and stable.

The latest 1.14 version of gitea has only this as the biggest significant change, the long streak of "stupid features" is ending and they start to put in deep and really useful features in the last months.

Gogs or gitea?

Particularly it depends more on the target:

If you want peace of mind and not to be always hanging on the system and have a real life, gogs, it just focuses on serving a git repo in the most simple without much party, gogs and its developer has the vision of simplicity always.

If you want more stuff, and you don't have a girlfriend or family, you need to customize everything, gitea allows you to have a system very close to gitlab or github without the complication of deploying (especially gitlab which is a pain).

Reasons that produced the change:

• One maintainer model
• Questionable leaks and past security practices.
• Panic in init if the working directory is not readable (!!)
• routes.go is handwritten and has to be updated manually.
• Encourages manual typing of URLs which ties up the way it is handled
• The JSON encoder actually stores the object completely in memory before generating the response which is also stored in memory before being transmitted.
• The translation framework (i18n) has a number of problems - the biggest being the requirement to list what languages are available and if there are errors there are no fixes unless they are regenerated.
• no compression handler
• session handling had to be rewritten.
  

Of course it should be noted that most of these reasons are specific to the developers' hasty and hirricane development mode, preferring ease of coding by sacrificing requirements on software complexity.

Conclusion:

The creators of gitea were always geeks rather than administrators, an admin does not want to live stuck in the machine, he has real life, so this is only valid for those who want to play.

Those changes where logical to be succeed one day, in the type of development they carry but detrimental in the maintenance of administrators (constant changes).

It has been noticed that with each release of gitea the amount of features has decreased considerably and now they are finally focusing on code cleanup and real depth changes