3 ms·

I'd recommend following the [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/ https://www.conventionalcommits.org/en/v1.0.0/) guidelines for

I'd recommend following the [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/ https://www.conventionalcommits.org/en/v1.0.0/) guidelines for writing the commit messages.

teeray 2y ago
I’d recommend against it. The most prominent aspect of it, the “feat:”, “fix:”, etc. labels, are better done with git trailers. The “module” that appears in parens could be another trailer, if you so desire. You don’t consume valuable bytes in the short message and you lose nothing in terms of search-ability. You could probably even use the trailer values to reconstruct conventional commit format if you really need to see it in that way.
- lucasoshiro 2y ago
  I won't recommend it specifically, but I recommend to have a standard. I prefer a standard that I don't like rather than a not having a standard. Other options that I remember: - The kernel patch descriptions: https://kernelnewbies.org/PatchPhilosophy https://kernelnewbies.org/PatchPhilosophy. Used by the repository that Git was created for (the Linux kernel) and Git itself; - Gitmoji: https://gitmoji.dev/ https://gitmoji.dev/, similar to conventional commits but using emoji Personally we may like them or not. But again, even though I don't like it, I would a history with "<bug emoji>: do foo in bar" instead of a history with a lot of commits only named "fix", "now it works" and things like that.
  - keybored 2y ago
    You don’t need a standard for everything. If standard means a machine-readable format. > Personally we may like them or not. But again, even though I don't like it, I would a history with "<bug emoji>: do foo in bar" instead of a history with a lot of commits only named "fix", "now it works" and things like that. It is good to have standards which will disqualify low-quality commit messages.
- noirscape 2y ago
  Scope labels are great, but I'd just recommend being super freeform with them. They can help encapsulate what part of a codebase is primarily impacted by them. Git trailers are neat, but ultimately suffer from a UI issue: most people are using interfaces to git that don't use the plumbing, and they put all the important info in the first line (and sometimes have a frustrating cutoff of 50 characters) and git trailers are considered a remnant that gets no special handling (if you're lucky, the Co-Authored-By trailer has special handling, but that's about it). If you're trying to quickly conceptualize why the history of a file is the way it is, then being somewhat consistent with scope labeling helps a lot. In practice, the style will just be different depending on the project. A hobby project doesn't need a hypervigilant git history, given you're usually just using git as a special save button. A rebasing fork will probably want to structure it's commits more on a per-patch basis (since they should be kept on top of all other commits), so most conventional advice doesn't make sense (since the git commit in this situation also acts as the code comment for the patches; you're usually trying to keep patches as small as possible for ease of maintenance). It's when you get professional that you'll want a commit style.
  - teeray 2y ago
    > Git trailers are neat, but ultimately suffer from a UI issue: most people are using interfaces to git that don't use the plumbing, and they put all the important info in the first line (and sometimes have a frustrating cutoff of 50 characters) It’s not git’s fault if you choose not to use git(1). Trailers work great with it. You can use other tools that claim some level of compliance with git, but you do so with the understanding that YMMV.
    - noirscape 2y ago
      I'm just going by the practical reality here; I personally do like using the git commandline, but the reality is that most people are using Git from forges like GitHub and terrible UI programs like, well, GitHub Desktop, which do both of these things. Ultimately git is a tool for version control and software collaboration, so what you end up doing should encompass the tools that people use. It's easier to find a compromise than to hardline on a position that requires a lot more upfront work (it's much harder to switch people off of software that they are familiar with than you might expect.)
keybored 2y ago
Why do you recommend it? I think it looks bad and doesn’t provide enough value for all the space it takes up.
- lucasoshiro 2y ago
  Having a standard is better than having no standard. If you don't like conventional commits probably you have a commit guideline that everyone in your team understands and follows and that is better suited for you case. So, it is not for you anyway, as the problem it solves is already solved for you.
fosterfriends 2y ago
I'll second it - consistency is better than perfect

I'd recommend following the [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/ https://www.conventionalcommits.org/en/v1.0.0/) guidelines for writing the commit messages.

teeray 2y ago

I’d recommend against it. The most prominent aspect of it, the “feat:”, “fix:”, etc. labels, are better done with git trailers. The “module” that appears in parens could be another trailer, if you so desire. You don’t consume valuable bytes in the short message and you lose nothing in terms of search-ability. You could probably even use the trailer values to reconstruct conventional commit format if you really need to see it in that way.

lucasoshiro 2y ago
I won't recommend it specifically, but I recommend to have a standard. I prefer a standard that I don't like rather than a not having a standard. Other options that I remember: - The kernel patch descriptions: https://kernelnewbies.org/PatchPhilosophy https://kernelnewbies.org/PatchPhilosophy. Used by the repository that Git was created for (the Linux kernel) and Git itself; - Gitmoji: https://gitmoji.dev/ https://gitmoji.dev/, similar to conventional commits but using emoji Personally we may like them or not. But again, even though I don't like it, I would a history with "<bug emoji>: do foo in bar" instead of a history with a lot of commits only named "fix", "now it works" and things like that.
- keybored 2y ago
  You don’t need a standard for everything. If standard means a machine-readable format. > Personally we may like them or not. But again, even though I don't like it, I would a history with "<bug emoji>: do foo in bar" instead of a history with a lot of commits only named "fix", "now it works" and things like that. It is good to have standards which will disqualify low-quality commit messages.
noirscape 2y ago
Scope labels are great, but I'd just recommend being super freeform with them. They can help encapsulate what part of a codebase is primarily impacted by them. Git trailers are neat, but ultimately suffer from a UI issue: most people are using interfaces to git that don't use the plumbing, and they put all the important info in the first line (and sometimes have a frustrating cutoff of 50 characters) and git trailers are considered a remnant that gets no special handling (if you're lucky, the Co-Authored-By trailer has special handling, but that's about it). If you're trying to quickly conceptualize why the history of a file is the way it is, then being somewhat consistent with scope labeling helps a lot. In practice, the style will just be different depending on the project. A hobby project doesn't need a hypervigilant git history, given you're usually just using git as a special save button. A rebasing fork will probably want to structure it's commits more on a per-patch basis (since they should be kept on top of all other commits), so most conventional advice doesn't make sense (since the git commit in this situation also acts as the code comment for the patches; you're usually trying to keep patches as small as possible for ease of maintenance). It's when you get professional that you'll want a commit style.
- teeray 2y ago
  > Git trailers are neat, but ultimately suffer from a UI issue: most people are using interfaces to git that don't use the plumbing, and they put all the important info in the first line (and sometimes have a frustrating cutoff of 50 characters) It’s not git’s fault if you choose not to use git(1). Trailers work great with it. You can use other tools that claim some level of compliance with git, but you do so with the understanding that YMMV.
  - noirscape 2y ago
    I'm just going by the practical reality here; I personally do like using the git commandline, but the reality is that most people are using Git from forges like GitHub and terrible UI programs like, well, GitHub Desktop, which do both of these things. Ultimately git is a tool for version control and software collaboration, so what you end up doing should encompass the tools that people use. It's easier to find a compromise than to hardline on a position that requires a lot more upfront work (it's much harder to switch people off of software that they are familiar with than you might expect.)

keybored 2y ago

Why do you recommend it? I think it looks bad and doesn’t provide enough value for all the space it takes up.

lucasoshiro 2y ago
Having a standard is better than having no standard. If you don't like conventional commits probably you have a commit guideline that everyone in your team understands and follows and that is better suited for you case. So, it is not for you anyway, as the problem it solves is already solved for you.

fosterfriends 2y ago

I'll second it - consistency is better than perfect