Moving forward for Standardized Git descriptions commits subject and descriptions when merging PR's with Master.

[acidmanifesto]

At times, looking at the git history can be a bit hard on the eyes as there seems to be no consistency with git commit subject lines and description.

Currently, you need to click on the pr id just to figure out what the commit is about.

This is only a suggestion with examples.
Why not put the pr# in the commit description and then the subjectline be in a formate of add/feat/fix/revert/chore, with area identifer in the title and brief summary less than 50 characters.

Then, for the body message, we list in detail the purpose of the commit, followed by pr# that was merged.

Start identifier:
Add: additional implementation of existing features
Feat: Adding new features not currently implemented
Fix: Fixing an issue or "bug" either reported or not
Revert: Reverting either a commit or partial commit
Chore: dependency update or white space/code style clean up, updating/simplifying methods/code blocks etc..

Area identifiers to follow:
Core: code base itself
Doc: documentation
Dep: dependiences
Misc: Miscellaneous

Summary:
Self explainatory, 50 chars or less

An example would be when we merge a pr:

SUBJECT LINE:
Fix (core): black screen issue

BODY DESCRIPTION:
fixed an issue with black screens yadda yadda.
Pr#12345

Something like this, moving on in the future, would make the githistory more readable and easily searchable with various git apps such as tortoisegit and others. Would possibly help in also researching past commits as well when attempting to identify any commit/issues dealing with anything ongoing.

Again, this is only a suggestion with examples. Really, it will be up to the project maintainers and admins to decide on what is appropriate.

Edited: typos

[acidmanifesto]

So the hopes of this is to help clean up and standardize the git history moving forward. However, the idea i suggested may not be exactly how the organization would want it done exactly. I figure we have a discussion before determining any PR being made for contributing documentation.

[ferferga]

I think a great step forward would be to kill merge commits completely in all repos. Having a linear history it's already a huge improvement imo.

A similar template to the one you're giving can be refilled by GitHub when squashing, but it's not always a good idea to squash unless the changes are really minor.

We also depend on others for this.

[grhallenbeck]

I think squashing is actually usually a desirable behavior. If changes are too big or complex for squashing to make sense, it likely means the PR covers too many concerns and should be split up if possible.

[ferferga]

@grhallenbeck Not necessarily, there are a lot of common instances where, for concern separation and keeping the relevant changes in history, rebase merges are desirable. A common example is when updating/modifying a eslint configuration: I usually do a commit for the config changes and another for the automatic fixes. That's related in the scope of a single PR, but not in a single commit.