search

emilyperica / ScoreGen

An audio to sheet music generator.
Other
1 stars 3 forks source link

Enforce naming convention of PR instead of commit #43

Open emilyperica opened 1 week ago

emilyperica commented 1 week ago

Since PR's are squash merged, their commit into main will be named after the PR itself. It is redundant to enforce commit names since they will not show up in the protected branch anyways.

stoiyeet commented 1 week ago

Since PR's are squash merged, their commit into main will be named after the PR itself. It is redundant to enforce commit names since they will not show up in the protected branch anyways.

If you're merging a single commit, the name will just be the the commit message, no? Here, my PR name is missing the colon but the commit message is not: https://github.com/emilyperica/ScoreGen/pull/27/commits

emilyperica commented 1 week ago

Since PR's are squash merged, their commit into main will be named after the PR itself. It is redundant to enforce commit names since they will not show up in the protected branch anyways.

If you're merging a single commit, the name will just be the the commit message, no? Here, my PR name is missing the colon but the commit message is not: https://github.com/emilyperica/ScoreGen/pull/27/commits

What do you think about having it run on PR and on push to main specifically then? The way it's setup now can become cause commits to fail unnecessarily, for example if you have a merge commit which shouldn't reference an issue at all.

stoiyeet commented 1 week ago

Since PR's are squash merged, their commit into main will be named after the PR itself. It is redundant to enforce commit names since they will not show up in the protected branch anyways.

If you're merging a single commit, the name will just be the the commit message, no? Here, my PR name is missing the colon but the commit message is not: https://github.com/emilyperica/ScoreGen/pull/27/commits

What do you think about having it run on PR and on push to main specifically then? The way it's setup now can become cause commits to fail unnecessarily, for example if you have a merge commit which shouldn't reference an issue at all.

Regarding the merge commits, I think we should just rebase instead of merging if you want the most recent code. Then for the automatic latex rendering commits, can we update the task so it parses the most recent commit and prepends its message with the same issue of the previous commit?