this post was submitted on 10 Oct 2024
1 points (53.8% liked)
JetBrains
172 readers
1 users here now
A community for discussion and news relating to JetBrains and its products! https://www.jetbrains.com/
Related Communities
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
Copyright Β© 2000-2024 JetBrains s.r.o. JetBrains and the JetBrains logo are registered trademarks of JetBrains s.r.o.
founded 10 months ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
@BatmanAoD Besides that a git log and a changelog have different target audiences.
The gitlog is intended for contributors of the project whereas the chamgelog is intended for users of the project.
And it helps the users if they get a summarized version of what changed for them.without having to.go.theough each commit amd decide for themselves whether and how that internal change affects the exteenal API and then their usage of it.
That makes sense to me.
I think I would still argue, however, that for projects using github, gitlab, or any similar forge with a built-in pull-request + code-review feature, there's very limited value in spending time crafting good commit messages in a feature branch. All information that you may be tempted to put there would be more visible and more useful either as code comments (which applies to all projects, not just GH) or as comments in the PR description or discussion. (I also think it's often better to just squash feature branches on merge than to try to maintain a clean branch history while the feature is in development.)
I do think that the commit messages that actually end up on your trunk are important; but, with the exception of the final PR merge (or squash) commit, developers should minimize the time spent writing or thinking about these commit messages.
The one context in which I find details in historical commit messages potentially useful is when using
git log -pto figure out when and why something changed. But even then, once I've found the relevant commit, looking up the PR to see if there was any discussion about the change in question is generally the next step; so again, having substantial detail in the commit message itself is unlikely to be helpful.@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.
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.
@BatmanAoD https://phpc.social/@freekmurze/113283034409214370
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.
@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 π
"trust them" meaning trust github and gitlab?
@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...
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.
@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