[noirscape]

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]

> 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]

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.)

[delusional]

If you limit your quality by what the lowest common denominator tool does you will guarantee that your process deteriorates until you're all just rolling around on the floor gurgling at each other.

The answer to "my tool doesn't render trailers" is not "let's waste the short message" it's "then don't use that crap tool"