Gitea: Add option to disable the web editor

[rikvdh]

• Gitea version (or commit ref): latest
• Git version: n/a
• Operating system: n/a
• Database (use [x]): n/a
• Can you reproduce the bug at https://try.gitea.io: n/a
• Log gist: n/a

Description

Currently the web-editor can not be disabled in the configuration. For some use-cases it is desirable to disable the web-editor.

[bkcsoft]

Care to elaborate on what kind of use cases those would be? If you don't want to use a feature, don't use it.

[rikvdh]

We are using Gitea within our organisation where we use Git-flow. To use Git-flow correctly we can't protect master/develop. But we want to prevent users making changes in these branches without the correct procedure. I cant prevent 10 developers to 'dont use' the web-editor and play police-officer all day. I want to disable it, and only allow source-code modifications through SSH.

I hope that clarifies my situation. :-)

[jhasse]

How can you prevent the developers from pushing the changes via SSH that they made in the web-editor?

[seeker20]

We have disabled this in the code. Unfortunately, the editor does not work with some code formatting. This deletes all lines and adds all lines again.

Problem is here, when the line endings formatted with CRLF and you edit it Online.

[lafriks]

I would prefer that problems are fixed than adding option to disable something just because of it.

@rikvdh is this problem sill actual for you as branches can be protected now?

[rikvdh]

@lafriks Unfortunately we are not able to protect branches due to the way we work. We want to disable the web-editor to prevent users to make changes by mistake in the wrong branches.

[lafriks]

@rikvdh how that would be different than from pushing changes to wrong branch?

[br-aw]

We need to disable the web editor, when someone clicks into it, it changes all 1000 lines and we can't reconcile this. Seems to be related to breaking the newlines.

[lunny]

Just like @lafriks said. This should be a bug of web editor we should fix it. But since web editor has the same permission control as SSH push. I don't think it's necessary to disable it.

[lunny]

Please send another issue to report a bug so that someone could fix it.

[JoshDreamland]

Another reason to disable the editor is because every single commit triggers our CI, and the editor only allows editing one file at a time. We have one contributor in particular who will edit files one at a time in his PR, spawning a separate CI instance for every file he touches, committing the same change to a half dozen files, one file at a time. I feel horrible about the sheer amount of compute power we completely waste on his behalf.

The latest PR I merged from this contributor changed five files, adding 62 lines and removing 27. In addition to his initial commit were forty-nine others, each made from the GitHub editor. He queued 2,250 jobs on Travis and another 900 on AppVeyor, burning three hundred core hours, all without a thought, by clicking buttons in the GitHub UI.

Note that we're open-source and don't pay for this service. We cost Travis some $15, today, and AppVeyor some $6, assuming their infrastructure scales well. I've asked this contributor in the past and will ask him again to stop doing this. But GitHub makes this so easy, I'm sure this is happening everywhere.

[lunny]

So maybe you mean gitea should support multiple files on web editor? :) but not disable it.

[bleonard252]

I would personally like to see something like GitLab's web IDE in Gitea.

[timurkelin]

using web editor can break the flow which involves git hooks

[guillep2k]

To disable the web editor (i.e the pencil icon to edit files online) you could edit Gitea templates and leave them out. Or probably much easier to maintain, add a custom CSS to make:

.octicon-pencil, .octicon-trashcan { display: none; }

I'm sure there's better selectors for that, but those should at least hide the icons for editing/deleting.

[guillep2k]

Another reason to disable the editor is because every single commit triggers our CI, and the editor only allows editing one file at a time. We have one contributor in particular who will edit files one at a time in his PR, spawning a separate CI instance for every file he touches, committing the same change to a half dozen files, one file at a time. I feel horrible about the sheer amount of compute power we completely waste on his behalf.

With code change suggestions (which we wish to implement in the future) this too will be a problem for you. I don't know if it's easy enough, but I'd configure my CI to kill any previous instances dealing with the same repo/branch when a new one appears. Still some useless work will be done, but it won't be so bad.