Commit message guidelines

[b1ek]

currently, everyone commits as they want to.

i dont like it because its inconsistent. we should figure out which commit style we'd adopt.

i propose this one:

type_of_commit: project_part: commit_msg

label	description
type_of_commit	one of: fix, feat, refactor, docs, misc and merge (allowed only for merge commits)
project_part	one of: stdlib, compiler, module X (in src/modules), tests (but not limited to these)
commit_msg	one english imperative sentence (such as rewrite X to be Y) in neutral tone describing what the commit does and that should not start with a capital letter

[Ph0enixKM]

Sometimes it's hard to determine the project part when commit carries some changes in multiple areas such as lib, bash optimization, syntax etc. at once.

How about we follow the looser version of this guideline:

type_of_commit: imperative_description

Are there any disadvantages to said form?

[b1ek]

Sometimes it's hard to determine the project part when commit carries some changes in multiple areas such as lib, bash optimization, syntax etc. at once.

How about we follow the looser version of this guideline:

type_of_commit: imperative_description

Are there any disadvantages to said form?

yeah, i guess that would make sense

[b1ek]

commit carries some changes in multiple areas such as lib, bash optimization, syntax etc. at once

hold on, isn't that just bad practice? like the way i see it is that there is only one commit per specific change, so that the git history is clearly readable.

for example, a series of commits clearly describes what happened: init: module: create module.rs -> feat: module: add function_x -> fix: module: fix bug in function_x -> init: tests: add tests for library.rs -> feat: module: integrate X.rs into module.rs -> feat: tests: extend tests for library.rs to include integration -> feat: compiler: use module.rs in compiler -> feat: tests: validate proper module.rs in compiler

instead of just one commit init: create module.rs to compiler with tests

(not to mention the enormous diff size)

[arapower]

I understand the benefits of splitting commits into smaller parts. But it might be a bit difficult to ask all contributors to be strict not only with commit messages but also with each individual commit.

[Ph0enixKM]

I agree with @arapower. It'd be a mess if we forced that to other contributors. I know that you like to keep things clean as possible @b1ek but since this repository isn't that large and we're still getting momentum - we should be more swift. We can always switch to the more strict pattern once Amber gets to the more stable and feature-complete versions. What do you think all?

[Ph0enixKM]

I'll convert this conversation to a discussion as it's in the discussions stage. We can create an issue based on it anytime.