export that cr*p out of whatever issue tracker you using. and merge commits are great
Git log is not a changelog
61–70 of 92 posts
Re: Git log is not a changelog
#62use https://www.conventionalcommits.org/en/v1.0.0/ , it has extensions that can autogenerate a nice looking changelog.
This is the kind of tools I dislike. It does generate a "nice looking changelog", but the result is not as useful as a separately written changelog, because the content is not curated, so the signal-noise ratio can be quite high.
Re: Git log is not a changelog
#63I find that many programmers are hyper-focused on writing automation for things that feel like a chore. This thinking has its purpose, but it’s almost an addiction. For these folks, putting deliberate effort into change logs, release notes, and documentation feels wasteful. My hunch is that this is due to a missing feedback loop: we are unlikely to get feedback about documentation, and more likely to get feedback on…
I think the reason programmers want to automate documentation is:
- they are programmers, automating things is their job, that's what they are good at, so of course they will do that
- there is the general "don't repeat yourself" idea. Documentation repeats the code so, ideally, if both are needed one should be generated from the other. Sometimes, the code can be generated from the documentation, but most of the times you can't, so documentation becomes secondary to the code.
Re: Git log is not a changelog
#64I completely agree with this. Every single project with « conventional commits » that try to generate release notes end up with completely useless release notes. Just bite the bullet and write for humans, it’s not that hard, especially if you do it on the fly as suggested by the post.
Re: Git log is not a changelog
#65Earlier quoted context omitted.
Never looking at git history is like, not reading comments or something. It's an incredibly valuable resource for understanding why the existing code is the way it is.
You didn't answer why. My code passes all the unit test and we almost always have real code using it immediately. The function works. Why am I reading it? The only thing I read are bug reports (usually a spec problem, not normally a logic bug) and new features, or test outputs
Because you'd want to know why code does what it does.
If a bug pops up, you'd want to know why some code exists and if the original premise of the code is as it should be or needs revision.
I think it's very rare that a developer receives all that information up front in a team. Eg. Old codebase, lost knowledge or people leaving.
Re: Git log is not a changelog
#66NixOS maintainer here and this is really annoying me since months. I can't really know what from a 100+ line git log is a breaking change and needs special attention and what is totally uninteresting for consumers of the piece of software.
Re: Git log is not a changelog
#67Most software is written for internal use and not sold to external customers. For this case Changelogs are busy work without much utility up until the point your organization is big enough that you and your "customer" may as well be separate companies. In that case you're better off writing a blog post or release announcement than a text file change log which is for grey beards, not users.
Re: Git log is not a changelog
#68Use multiple "-m" parameters in your git commit. git commit -m "feat: script pretty print" -m "added variables for bold, normal, and a nice blue arrow" becomes: feat: script pretty print added variables for bold, normal, and a nice blue arrow In your git log output. Use extra "-m" sections for stuff like ticket references, or other relevant information like a link to a design document.
Alternatively just avoid the `-m` flag and open the message in `$EDITOR`
Re: Git log is not a changelog
#69Earlier quoted context omitted.
I'm starting to understand why. It appears my workflow has the information other people would want from a git log elsewhere (test, specs, examples, etc)
Let's say you have some code written 2 years ago. 2 months ago someone made a bug fix in the code replacing a few of the lines. How would you know from test, specs or examples which specific lines were modified and by whom? I don't get it.
Why would I want to do that?
Usually if there's a problem I'll either write a new test or see if someone modified a test I thought was covering the case
Usually people 'own' a file or part of the system so that wouldn't really be happening anyway
Re: Git log is not a changelog
#70Earlier quoted context omitted.
To explain why a certain block of code exists. When the code came into existence is rarely that important. You just want to know why. Why does the code fence against a particular circumstance you didn't think should be possible? Why does it call out to something you think is unrelated? Those questions can be answered by a proper commit message.
I set a breakpoint and run the test suite for that answer
No post body was provided.