I don't like this.

I don't like this.

Writing guidelines on how commits should preferably be written should be a good idea in any case.
Is your preference the format package: some description?

Writing guidelines on how commits should preferably be written should be a good idea in any case.

This is true. We have seen a bunch of PRs of which the subject is not comprehensive.

Yes I prefer package: Some description and new package: pkgname, because I believe they are comprehensive and easy to write.

Yes I prefer package: Some description and new package: pkgname, because I believe they are comprehensive and easy to write.

I decided to draft this proposal in order to make commit messages more uniform and make history easy to browse. This commit guideline is inspired by Node.js and Arch Linux's commit messages. In case you have any better idea in your mind, feel free to share. After all, it doesn't matter how good the proposal is unless all (or most) of the existing collaborators agree to it.

My proposal:

• If a commit is about to modify a single package, then the subject should contain the package name.

And only this. Unnecessarily complex rules are just hard to obey.

How long should commit message be?
I still prefer xtkoba's way as well since the proposal add quite a bit characters and not fit 50 chars for long package names...

The suggested rules by @thunder-coding look good to me too. They are following the conventional commit design, which is used by lot of FOSS projects now and also the termux apps repos mostly. Deciding scope as package name is easier here than app components though.

https://www.conventionalcommits.org/en/v1.0.0

This issue/PR has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@thunder-coding #11281

Lol it's the typo I made earlier, which I fixed somewhere between. It's upgpkg only standing for upgrade package.

Anyways it's inspired by Arch's commit messages used in their VCS.

About adding scripts to lint commit messages, I don't think that's the priority for me now. In case anyone is interested in it, I would be very glad. Atleast I don't expect me to work on it. In case everything seems good, and I get a approving review, I'll format the markdown file, (possibly affecting other lines than the changed ones too), and merge it.

Let's finally get this merged. I see a lot do new PRs following similar guidelines, so making it official from semioffical might be worth it :)

adapt commit messages to new guiselines

What's that? Second typo ;)

adapt commit messages to new guiselines

What's that? Second typo ;)

So you've been spying on the commit log where you saw the old typo fix :) Anyways fixed. Thanks\

So you've been spying on the commit log where you saw the old typo fix :) Anyways fixed. Thanks\

When a dev opens a pull request about proper commit messages and then pushes commits with the title adapt commit mwssages to new guiselines, there is obviously fun to be had ;) And welcome.

I'll merge this PR tommorow if there are no changes requested by anyone else.