Default merge policies per repo (better ui? better docs?) #469

Open
opened 2 months ago by dyfet · 4 comments
dyfet commented 2 months ago

Some groups have specific policies that always require squash merges. This is always a contentious issue because there are different opinions about what this really means to project histories.

Github for a long time allowed the ability to set a squash merge as the default merge policy for a repo. For multiple years this was the #1 feature request on gitlab, and some refused to use gitlab, or even abandoned using gitlab, because of this, until finally ?last year? when they also made the ability to define merge policy defaults on a per-repo basis.

In the case of gitea this normally may play out differently. Because it is simple to build, I imagine those who really require and mandate squash merges probably would just maintain a patch to make that the default behavior globally for their own build, or submit it as a global option patch. However, in the case of something like codeberg, where different developer communities co-mingle, having a single global policy that will make everyone happy seems rather unlikely. So I am suggesting that for sites like codeberg, gitea also adopt the ability to have some kind of per repo default merge policy setting, too.

Some groups have specific policies that always require squash merges. This is always a contentious issue because there are different opinions about what this really means to project histories. Github for a long time allowed the ability to set a squash merge as the default merge policy for a repo. For multiple years this was the #1 feature request on gitlab, and some refused to use gitlab, or even abandoned using gitlab, because of this, until finally ?last year? when they also made the ability to define merge policy defaults on a per-repo basis. In the case of gitea this normally may play out differently. Because it is simple to build, I imagine those who really require and mandate squash merges probably would just maintain a patch to make that the default behavior globally for their own build, or submit it as a global option patch. However, in the case of something like codeberg, where different developer communities co-mingle, having a single global policy that will make everyone happy seems rather unlikely. So I am suggesting that for sites like codeberg, gitea also adopt the ability to have some kind of per repo default merge policy setting, too. <!-- NOTE: If your issue is a security concern, please send an email to contact@codeberg.org (and if related to Gitea also to security@gitea.io) instead of opening a public issue. Thank you. Welcome to the Codeberg Community Tracker. This is the right place for bug reports, feature requests and feedback. It's the central place where we track progress and discuss, so please open issues here unless you are sure it's directly related to a specific Codeberg product and only some contributors there need to join the discussion. Easy rule: If you are unsure, report it here. When reporting bugs or asking for features in the software itself, please understand that Codeberg is a fork of Gitea. Please always check upstream (→ see FAQ) if your there is already an open issue. If not, you'd really help us if you could directly get in touch with the maintainers and open an issue here if you think a wider audience should know about that (e. g. when discussing hotfixes, backports or when discussing whether some feature should become part of Gitea or a Codeberg "add-on"). If you don't have a GitHub account, please mention this and we'll gladly forward your report to the Gitea maintainers. Thank you for reporting your findings and giving feedback on Codeberg. ## Some FAQ: ### What does upstream mean? Upstream refers to Gitea, the software Codeberg is built upon. If we ask you if you can report upstream, please visit https://github.com/go-gitea/gitea/issues and check for the bug there and report elsewise. It's usually good if the person interested in a feature or bugfix opens the request to react to questions and join the discussion. We would usually just fire the report, but won't find the time to properly react to that ... **If you do not have a GitHub account**, just tell us and we'll happily forward the report for you. ### I just noticed a typo in the sign_up / sing_up route when regis... No, this is not a typo, but intentional. It was a quick fix to avoid spammers targetting our instance and it actually worked out quite well to rename the route from sign_up to sing_up (few people notice, nice to see you have sharp eyes) ... we might have to take more effective countermeasures in the future, but for now we're actually quite good with that one ... ### How can I help? If you want to help improving Codeberg as a community home for software development, we'll gladly welcome your contribution. Check out the docs about improving Codeberg https://docs.codeberg.org/improving-codeberg/ and have a look at the open issues, especially those that are looking for contribution https://codeberg.org/Codeberg/Community/issues?state=open&labels=105 - some of them don't even require much coding knowledge. We are also happy if you forward bug reports to Gitea if the original author hasn't done that yet or hasn't got a GitHub account. -->
dyfet changed title from Default merge options to Default merge policies per repo 2 months ago
fnetX added the
question
label 2 months ago
Collaborator

In the settings, you can enable and disable all kind of options for Merges that should be available, although a default cannot be set. Is this enough?

If for example you want to squash pulls, just disable everything but this option, and the green button will always squash. Settings look like this:

image

If this isn't enough for this use case yet and you have a GitHub account, please check for this issue upstream and report there. It's always good if someone who checks this in is available to respond to requests and / or comment on the design. Otherwise, just tell us and we'll eventually open the request. I think having a default selection for a repo sounds like a good idea.

In the settings, you can enable and disable all kind of options for Merges that should be available, although a default cannot be set. Is this enough? If for example you want to squash pulls, just disable everything but this option, and the green button will always squash. Settings look like this: ![image](/attachments/ced94d2a-6a70-4cd1-92bc-cc3b5ed58e67) If this isn't enough for this use case yet and you have a GitHub account, please check for this issue upstream and report there. It's always good if someone who checks this in is available to respond to requests and / or comment on the design. Otherwise, just tell us and we'll eventually open the request. I think having a default selection for a repo sounds like a good idea.
Poster

@fnetX you are absolutely correct! I would not have guessed offhand that it worked that way ;). But yes, that absolutely does what I would want! I am tempted to close this issue...

@fnetX you are absolutely correct! I would not have guessed offhand that it worked that way ;). But yes, that absolutely does what I would want! I am tempted to close this issue...
Collaborator

Well, every behaviour that is not really obvious should either be documented or improved to make the UI more intuitive IMHO.

I had to play with this as well, and it was probably more of luck that it worked out this way.

A feature request might still make sense.

Well, every behaviour that is not really obvious should either be documented or improved to make the UI more intuitive IMHO. I had to play with this as well, and it was probably more of luck that it worked out this way. A feature request might still make sense.
Poster

Then let's leave it open, at least for other feedback. Naybe it could simply be documented somewhere on the site, or maybe the ui should be improved to be more obvious...

Then let's leave it open, at least for other feedback. Naybe it could simply be documented somewhere on the site, or maybe the ui should be improved to be more obvious...
dyfet changed title from Default merge policies per repo to Default merge policies per repo (better ui? better docs?) 2 months ago
fnetX added the
gitea-related
enhancement
labels 2 months ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.