JetBrains

171 readers

1 users here now

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

Related Communities

founded 10 months 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 1 month ago by [email protected] to c/jetbrains

42 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] 2 points 1 month ago (1 children)

@BatmanAoD Having done code archeology for over a decade now I can assure you that the issue with all the information that you need to understand why something was done has been discarded just shortly before due to moving to a different platform... Or something similar.

In any case: Having all the relevant data in one place and not scattered is a huge advantage.

[–] BatmanAoD 1 points 1 month ago (1 children)

I mean, I've been doing this for over a decade too. If teams are losing data from their issue tracker or source forge, that's a deep problem and not something that can be ameliorated by writing better commit messages.

[–] [email protected] 2 points 1 month ago (1 children)

@BatmanAoD https://phpc.social/@freekmurze/113283034409214370

[–] BatmanAoD 2 points 1 month ago (1 children)

They are hard to discover… and hard to use.

Flippin' fantastic, that's exactly what I want out of my documentation tooling.

I absolutely agree it would be better if forge data were part of the repo itself rather than separate. But for teams that are using a forge in the standard way, they should rely on the forge for this sort of thing, rather than hide important information in an obscure git feature.

[–] [email protected] 1 points 1 month ago (1 children)

@BatmanAoD It all depends on the maturity of the toolchain... and the longtime availablility of the external dependencies 😁

And. I no longer trust them further than I can spit... 🙈

But YMMV 😁

[–] BatmanAoD 1 points 1 month ago (1 children)

"trust them" meaning trust github and gitlab?

[–] [email protected] 1 points 1 month ago (1 children)

@BatmanAoD Whatever tool people are using for their issues and/or PRs and/or VCS

And it's not about trusting the tool but trusting that the tool will always be available. Whether due to discontinuation of the tool itself or due to discontinued use of the tool and replacement by something else...

[–] BatmanAoD 1 points 1 month ago (1 children)

To be clear, you're saying you trust git metadata to be preserved even when forge/issue-tracking/etc metadata is not?

I suppose that's probably the case more often than not. I think it's still preferable to trust the forge you use than to spend any significant amount of time or effort trying to ensure that the team has strong enough commit-message discipline to compensate for the risk of losing data in an issue-tracker or forge.

[–] [email protected] 2 points 1 month ago

@BatmanAoD so far I have seen more issue-trackes come and go than VCSs...

So yes: Training developers in commit-discipline would for me not be wasted time and money.

Cause from what I have seen so far the question is not *whether* the issue tracker changes but *when*.

But OTOH: That's just me (and some companies I worked at).

YMMV