Better commit messages might help users understand the intent behind our changes.

[poeschlr]

@jkriege2, @evanshultz, @Ratfink, @Shackmeister, @Misca1234

There is a justified complaint over at the mailing list about our careless use of commit messages in the library repos: https://lists.launchpad.net/kicad-developers/msg35661.html
Edit: just to clarify, I am at least as guilty of all charges as everyone else here.

So we might want to take better care of that.

If you guys merge a change you can add a merge message where you can summarize what you merged. (If the contributors commit messages are not descriptive enough)
If the git history of the contributor is extremely bad we might even want to use the squash commit feature which replaces all commits by a single commit and again allows the merging party to define a descriptive message for it.

---

A good guide might be: https://chris.beams.io/posts/git-commit/

---

Another edit:

Most commits by normal contributors can be summarized as a squashed merge with the commit message containing the information of what has been added. (Fixes are mostly done by us maintainers anyways so the harder commit messages will fall under our responsibility.)

[Ratfink]

Absolutely! A clean Git history is a beautiful thing. I don't claim to be free of sin here, but I always limit the first line to 50 characters, and usually try to write a paragraph or two unless 50 characters can really summarize the changes. Sometimes my commit message bodies go into too much too much technical detail, so I definitely have things to work on still. But yes, I will remember to use squash merges when a PR has rather messy commit history from now on.

We might want to add some information about this to our contribution guidelines on the KiCad website, to try to get nicer commit messages from new contributors so we won't have to squash their branches.

---

As a semi-aside: why is this an issue?

By this, I of course don't mean, "why should we have a cleaner Git history?" I've thought our history was awfully messy in the past, but I had little motivation use strategies like squash merges in KiCad library repositories myself because that would be against what everyone else was doing. Fixing our rather cavalier attitude towards commit history would be great.

What I mean is, "why is this an issue on the tracker?" What criteria will be used to close this issue? It's not as if we can go back and change our Git history, then when all past commits have good messages, this can be closed. The "fix" to this is a continuous, ongoing effort from all librarians. I feel like this sort of post would be better written as a team discussion on GitHub, or as a message to the kicad-lib-commiters mailing list on Launchpad if we're sure all the team members here are on that list (if we want to keep that list around, we should definitely make sure of this!).

[poeschlr]

I didn't even know about team discussions. For some reason i don't get notifications for them.

[antoniovazquezblanco]

Can this be closed?

[Misca1234]

Can this be closed?

I guess so,

I also feel that "good git commit comments" is not that valid for symbols/footprint/3D models but more for source code.

Almost all that is merged into the libraries are single entities addition, what would be a a good commit messages for those which is not "completely" covered by the fact that the whole entity is added ?

[antoniovazquezblanco]

Thank you. I will then close this.