You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I see in the branch rules that all branches are by default protected and only accept new commits through pull requests. Was this setup chosen to ensure the branches remain available in the future? If not, what is the reason for this protection?
If so, I would like to propose a different setup as the current one introduces issues with using gitautopush. Currently, only members with admin rights would be able to push directly to a branch. Although almost everyone is currently an admin (not a smart setup), this setup would defeat its purpose in my opinion.
Instead of relying on branch protection, couldn't we make use of tags(/releases) for archival purposes? By adding a tag to the branch after the workshop (or even creating a release to create an easy-to-download zip-file) we can avoid the use of generic branch protection and in fact delete branches of previous workshops altogether. With a tag in place, you would always be able to restore a branch.
Let me know what you think
The text was updated successfully, but these errors were encountered:
@mwakok Fine with this suggestion. The old setting had not much thinking behind it, and I am very glad to be led there. I cannot think of any objection to a leaner setting, so long as the people changing this repo are recognised members of the 4TU.R*D* organisation. Anything that is in keeping with the general usage principles of the organization looks fine to me.
I agree with @mwakok, it might be a better way to do things, especially since Data Carpentry workshops have started using this repo, too, it could get unruly pretty quickly. Maybe something for @halfordd to implement (if we choose to continue using this option for notes)?
Hi @wmotion,
I see in the branch rules that all branches are by default protected and only accept new commits through pull requests. Was this setup chosen to ensure the branches remain available in the future? If not, what is the reason for this protection?
If so, I would like to propose a different setup as the current one introduces issues with using gitautopush. Currently, only members with admin rights would be able to push directly to a branch. Although almost everyone is currently an admin (not a smart setup), this setup would defeat its purpose in my opinion.
Instead of relying on branch protection, couldn't we make use of tags(/releases) for archival purposes? By adding a tag to the branch after the workshop (or even creating a release to create an easy-to-download zip-file) we can avoid the use of generic branch protection and in fact delete branches of previous workshops altogether. With a tag in place, you would always be able to restore a branch.
Let me know what you think
The text was updated successfully, but these errors were encountered: