JetBrains

201 readers

2 users here now

A community for discussion and news relating to JetBrains and its products! https://www.jetbrains.com/

Related Communities

founded 1 year ago

MODERATORS

Vacant

After seeing people use the UI to commit to git I understand where all those - sorry: shitty - commit messages come from.... (phpc.social)

submitted 4 months ago by [email protected] to c/jetbrains

34 comments fedilink hide all child comments

After seeing people use the @jetbrains UI to commit to git I understand where all those - sorry: shitty - commit messages come from....

🙈

An improvement would already be to have a "Subject" line and the text box.

And have the subject line follow the Beams Rule.

Sonthat the first line of the commit message finishes the sentence

"When this commit is applied it will..."

And please: No longer than 56(?) characters (Unicode). Keep it short. You got the textbox to explain *why* in full length.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] -1 points 4 months ago (1 children)

@ramsey Just: Don't.

The subject lines space is limited and should not be wasted for stuff that doesn't belong there.

Also the prime idea behind conventional commits is to add machine readable info.to the commit message: Fine. Do so. The commit.meysage can be as long as you want. Add it there. Keep the subject line to the human readable part.

Also: Creating changelogs from.git.commits is *not* what chamgelogs are there for.

Keep a changelog can help on *that* front.

@jetbrains

[–] BatmanAoD 3 points 4 months ago* (last edited 4 months ago) (18 children)

Why should I put manual effort into separately maintaining a changelog and a semantically meaningful commit history? If I'm going to manually maintain atomic commits with useful commit messages, why would I want the contents of those messages to be substantially different from the content of the relevant bullets of the changelog?

[–] [email protected] 1 points 4 months ago

@BatmanAoD Because they serve a different purpose.

Purely semantically a changelog is something different than a git log (otherwise it would be named a git log).

The changelog is more a log of merges that describes the main overview of new features and also bug fixes.

If I want to know the exact details why this line of code changed, *then* I look at the git log.

Having all atomic commitlogs in the changelog tells the user that you are too busy fixing code to give them a meaningful summary

load more comments (17 replies)