[HN Gopher] Subject-First Commit Messages
___________________________________________________________________
Subject-First Commit Messages
Author : s4i
Score : 81 points
Date : 2024-01-01 14:25 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| rco8786 wrote:
| I think I would prefer this style.
|
| And also the discourse around commit messages and their various
| flavors may be one of the biggest wastes of time in terms of ROI
| in our industry.
|
| I've been doing this for 14-15 years and can probably count on
| two hands the number of times I've needed to look at historical
| commit messages.
| naavis wrote:
| I don't know, I do it almost daily. So your mileage may vary.
| sverhagen wrote:
| I do it almost daily too. What _is_ rare, is finding a commit
| message that tells me anything useful that I couldn't have
| derived from the diff also. I don't need your life story, but
| sometimes some context about why something was needed is
| great.
| rco8786 wrote:
| Exactly. Im in _git history_ all the time. But the messages
| themselves...eh. Im basically always looking for a change
| in a specific file or set of files, and then I just pull up
| the diffs.
| madeofpalk wrote:
| What I do find useful is the subject/area, and the author.
| mewpmewp2 wrote:
| It is so odd to me as I don't remember a single instance
| during my 10 years of experience having done that. Only if I
| was asked by someone else in the org why something is the way
| it is have I gone to history to see what the ticket number is
| for the referred change to get an explanation and this is
| more related to the product.
|
| I wonder what is so different about our workflows, that some
| people do it all the time and others almost never.
|
| Are we working on somehow very different things.
|
| To me I find that code is the source of truth and current
| state, it doesn't really matter to me as much why or how
| something came to be as I look more into how I can make the
| current thing work with what I am to do.
| g-b-r wrote:
| Maybe you don't debug bugs? Work on recent and clean
| codebases?
|
| Or simply the projects you work with have poor commit
| messages?
| mewpmewp2 wrote:
| I do, and I also work on legacy systems. It just never
| occurs to me that commit history would somehow help me
| instead of just looking at the current state of the code.
|
| I would say however that the commit messages mostly are
| just squashed pull requests with ticket names and single
| sentence so I'd agree that they wouldn't be very good for
| that purpose, but I don't see anyone at the org
| complaining about this.
|
| It's mostly on the Internet I read how others use the git
| history, but I haven't seen anyone really doing a lot of
| that in real life.
| marginalia_nu wrote:
| It does sort of feel a bit cargo culty sometimes. I expect
| commit messages are situationally important, as a function of
| the size and maturity of the project, the size of the
| development team (esp. the amount of developer churn).
|
| That said, there's probably some fringe benefit to describing
| what you do in some fashion. It's a great way of making sure
| you understand what's happening yourself.
| g-b-r wrote:
| I find much more cargo cult in disregarding commit messages
| marginalia_nu wrote:
| How does that work? Like a cargo cult behavior is a ritual
| you do because you think it will bring about some good
| through unknown means. Disregarding commit messages is the
| absence of a ritual.
| azornathogron wrote:
| I look at past commits probably every week or two to track down
| why something is the way it currently is.
|
| Having said that, I care very little about style and grammar of
| commit messages. Ideally I want them to say why the change was
| made, what the intended effect was, and where I can look for
| related work (bugs that tracked the work and have related
| commits or investigation attached to them, docs, whatever)
|
| Hit rate on the information I'd like is not great, but if I get
| at least one of the three things then it's something I can work
| with.
| w0m wrote:
| I'd say I look at commits ~weekly, especially when trying to
| understand 'WTF did he do that?' - context of tracing the
| commits (and offtimes back to individual PR when commit is
| poorly formatted) is valuable.
| tsimionescu wrote:
| I personally look more often at past commits, but I've still
| never really had a need to scan a list of changes like this. I
| really don't see the point of the advantage they're claiming,
| even if it's real.
|
| What I normally do is, while investigating a tricky bug and
| finding some lines that don't make sense, look through history
| to see why those lines were introduced (to see if they fix
| something else), and perhaps when (to see which versions may be
| affected by a hard-to-reproduce bug). But that typically
| pinpoint a commit already, and I just need the commit message
| to explain why it was there.
| safety1st wrote:
| What's tremendously useful for us to have in the commit
| message, is the ticket ID the work is related to in our issue
| management system, to the point where it is practically
| mandatory.
|
| I see it as a matter of scoping communications. The issue
| management system includes a broader set of people than the git
| repo. You want the commit linked to the issue so that you can
| see the entire history behind the commit, including the
| business decisions, the designer making a call, the back and
| forth with QA etc. That can all be useful a year or two down
| the road if you want to understand why something was done a
| certain way.
|
| Now there is some info about the change that perhaps only the
| devs would ever care about, and probably that can sit in the
| commit messages. That sort of happens naturally but there's not
| really a lot of it for us. But that seems to me to be the
| relevant thing from an organizational perspective, no one
| writes commit messages except for devs, and almost nobody
| except the devs reads them.
| Scubabear68 wrote:
| This is what I came here to say. Assuming the team is working
| from JIRA or something, put the ticket number in the commit
| message. The ticket itself is where your "why" goes.
| mook wrote:
| It's really nice to have the actual reasoning in the commit
| history though. But maybe I was just scarred by the project
| that switched project management software like 5 times over
| its lifetime (but kept all of the commits) though.
| aaronbrethorst wrote:
| I've been through this in a job. The commit messages were
| borderline worthless, ostensibly the context was in a
| JIRA ticket that hadn't existed in a decade, and I
| couldn't figure out if a change was a mistake or
| something clever and poorly documented. It's frustrating,
| a huge waste of time, and runs the risk of introducing
| subtle defects into the code today.
| davidjfelix wrote:
| I can't stand the ticket number in the message. It's an
| immediate waste of 6-10 characters on meaningless metadata
| that GitHub can pull from the body and link for you.
| Further, the numbers are sequential, so frequently VERY
| similar, and highly prone to typos, which is harmful to
| anyone even minorly dyslexic.
| bob1029 wrote:
| Blame & diffs are much more useful to me in the context of
| GitHub. I don't care about someone's subjective ~50 char
| description of a change. The important part is the pull request
| itself and that it references whatever issue prompted the
| change.
|
| Commit messages have only ever been useful in tracking _my own_
| intermediate work products. Often times, I will leave helpful
| bread crumbs in my commit notes if I know I won 't be working
| on something for a few days. We strictly do squash+merge, so I
| don't have to worry about these things causing trouble for
| others. All of our commits into master have some standardized
| "Issue #1234" note as automatically copied from the PR title
| (which we _do_ have ~standardized).
|
| If we _didnt_ have some git wrapper like GitHub available, then
| I suspect we 'd be significantly more aggressive with policy
| around our commit messages.
| g-b-r wrote:
| If your process requires trashing the commit messages it's
| not surprising you don't find them useful.
| atoav wrote:
| Bottom line first. I like it.
| Salgat wrote:
| In my experience consistency is more important than any specific
| style of commit messages. Similar to style guides for code;
| there's plenty of ways to approach it, but the real value is the
| consistency in how things are written across all developers.
| henning wrote:
| Like everything in software development, this is just personal
| preference without any actual evidence, a substitute for actually
| making software with quantitative quality metrics that users
| actually care about. Let's fiddle with our commit messages, PR
| formats, code formatting, etc. etc. etc. instead of addressing
| the fact that our website has 6 different fonts and makes 30 HTTP
| requests to show a few hundred bytes of text.
| idlephysicist wrote:
| I totally agree, I have seen people get so fixated on this in
| addition to:
|
| - review feedback format
|
| - variable naming
|
| - keeping line lengths to 80 lines
|
| - log message formats (sweet jesus the amount of time wasted
| debating that alone)
|
| Whenever I see these conventions about commit formatting they
| generally seem to focus on the first line (notable exceptions
| being Git and the Linux kernel among others I assume), one line
| is rarely enough to describe the change - I'm not advocating
| for writing an essay for a 5 line change though in some cases
| it might be warranted.
|
| Professionally I rarely see useful commit messages, by useful I
| mean something that could be read by someone without context
| and get a general understanding of why a change was made.
| Frequently I have seen "updates" / "wip" etc. in the master
| branch. More frequently I see that the quality of commit
| message decreases with an engineer's seniority - though like
| every thing there are exceptions.
| egnehots wrote:
| there are pros and cons to both verb-first and subject-first
| commit styles.
|
| verb-first commits can be organised in a few categories. since
| they are few commit verbs (fix, add, refact..), always use the
| same verb prefix for bug, features messages and you will have
| nice categories to scan/filter:
|
| - add feature
|
| - fix bug
|
| - refactor logic
|
| On the other hand, subject-first indeed put the important part
| first and let you _search_ for a term:
|
| - Instance configure template method called from constructor
|
| - Store's project method is an alias for fetch
|
| - Title is changed
|
| Depending on the use case, are you often searching for something?
| or would you like to highligh the nb of bugs/features in the last
| release?, one style is better suited than the other.
|
| For important changes, I like the linux kernel style: oneline
| summary, details (problem, impact, solution..)
|
| https://docs.kernel.org/process/submitting-patches.html
| laerus wrote:
| After started using conventional commits [1] for my messages the
| style of Subject-First commit messages comes almost naturally.
|
| [1] https://www.conventionalcommits.org/en/v1.0.0/
| tahnyall wrote:
| I prefer the first version, I didn't find the second version to
| be more "scannable" and it seems to me to be more esoteric
| requiring study to realize what was recorded. The first version
| is clear, each commit makes sense and is what I'd be grepping for
| when trying to find a commit.
| knorker wrote:
| This seems super subjective, while being written as if it's not.
|
| I find this way WAY harder to read/scan, and very much prefer
| Google's standard: https://google.github.io/eng-
| practices/review/developer/cl-d...
| davidmurdoch wrote:
| What is CL here?
| tuwtuwtuwtuw wrote:
| Change List. Similar to pull request I think.
| tsimionescu wrote:
| "Change List", Perforce's name for the rough equivalent of a
| commit.
|
| It's called a change _list_ even though it 's a single commit
| because Perforce tracks changes per file, so if you modify
| multiple files in a single commit, you are introducing a list
| of changes in their model.
| knorker wrote:
| Sorry, yeah I should have clarified that. For the purposes of
| the topic at hand, "CL" is "commit".
| king_geedorah wrote:
| CL stands for change list. https://google.github.io/eng-
| practices/
| asylteltine wrote:
| This doesn't work with conventional commits which is flat out
| awesome. But I will try mixing both because I like the idea
| ikari_pl wrote:
| Error messages. Get to the meat of it in the first 3 words,
| there's a high chance that's the only part that will get read, or
| even displayed. It must be the most meaningful part of the error
| message.
| twodave wrote:
| I look at commit messages every day. I actually don't love a
| message that just describes the code change (I can figure that
| out on my own if I look at it long enough). That's fine for
| bigger or more misleading changes, but when I'm looking at
| blame/history I'm usually very aware of what the code is doing
| already. My question at those times is less about "what" and more
| about "why". Why was this change made? Sometimes that can be
| found by looking at accompanying tests (if the original author
| was so gracious), but if it's not in the commit (or only obtusely
| so, as many developers I know tend to commit in what I'll call
| "stream-of-consciousness" style) then I've got to go outside the
| codebase to research by interviewing people (assuming they're
| still around and remember) or trawling through our project
| management system to try and line up released features/fixes with
| the change. It quickly becomes an inexact science.
|
| That said, in my experience, the larger an organization, the more
| commit messages get looked at. On my side projects where only 1-3
| people are involved, commit messages only really show up on the
| PRs as things are going in. Sometimes we complete our own PRs to
| keep up the velocity since we're all working async part-time.
| Rarely if ever do we look back to figure out why we did something
| because the project is so small.
| BoxFour wrote:
| > My question at those times is less about "what" and more
| about "why". Why was this change made?
|
| Isn't the essence of the commit message body to delve into the
| 'why'?
|
| The ability to swiftly glean the 'what' from the commit subject
| line aids in identifying the appropriate commit for review. The
| commit message body can then have a detailed explanation of the
| reasons behind the change.
| jbverschoor wrote:
| The diff is the what. Putting what in the message is fluff to
| make gatekeepers happy
| masklinn wrote:
| Disagree.
|
| Putting "what" in the message _can_ be fluff, in the same
| way _repeating_ the code in a comment is fluff. But the
| broad strokes or considerations of the what may not be
| obvious from the diff. Expressing what the commit intends
| as prose can help with understanding, with discarding
| irrelevant change data, with post-mortem analysis, ...
| vitus wrote:
| It is also useful for conveying intent. If the commit
| message describes one thing, and the code does the
| opposite (or doesn't do it at all), that's something the
| "gatekeeper" can and should call out.
|
| I've certainly sent out changes for review where I forgot
| to include a crucial file (or subdirectory).
| withinboredom wrote:
| About to say this as well, but would like to add. When I
| have a bug dealing with Foo in Bar, seeing a commit
| message like "Updated Foo to support Baz\nSee issue #123
| for additional context. Also discussed in chat (link)."
| When looking for a recent bug, I'm going to review that
| commit immediately without having to do any
| bisecting/blaming. Easy peasy.
|
| Mostly though, I tend to see just "support baz" as a
| commit message, which drives me bonkers.
| BoxFour wrote:
| In bigger teams, scanning every diff instead of just the
| commit subject lines is significantly more time-consuming
| (a frequent activity in my experience).
|
| I often decline proposed commits that lack concise,
| informative subject lines, and I hope other larger teams
| also do for efficiency and clarity. If that's considered
| gatekeeping, then I'm content to be one.
| g-b-r wrote:
| Understanding a diff usually requires knowing and
| remembering the codebase well, having a very clear code,
| the diff being reasonably short and atomic and time.
|
| Commit messages, if good, are extremely helpful to check
| what changed e.g. in an open-source application you're
| using. Of course the commit messages can lie, so you should
| also check the diffs, but it's much easier to _confirm_
| what a diff does than deducing it.
|
| Not to mention that for many changes you can only make a
| guess at what the intention was; if you have a message
| saying what was meant to be done, you can check that it
| _really_ was done correctly.
| ordu wrote:
| There are different levels of "what".
|
| 1. I'm moving value from this address to that address
| through %rax register.
|
| 2. I'm copying this value from that place to that.
|
| 3. I'm making sure that this values are equal.
|
| 4. An invariant was broken and I need to restore it.
|
| If you look at it, each next like is an answer to "why"
| question applied to a previous line. Answers to "why"
| questions becomes new "what" and then "why" applied to them
| again.
|
| The point I want to make is it is easier to move back (in
| descending order) through this than forward. When you know
| (4) you can easily figure out what is needed to be done.
| But if you have (1) you need to infer next points one by
| one. One who just wrote the patch is probably unaware of
| differences, because he knows all the answers and can
| easily move from one to another. He/she do not feel
| difficulties. But the person who reads patch starts with
| (1) and needs to climb the ladder in opposite direction
| than the person who wrote the patch.
| masklinn wrote:
| I agree with your first paragraph, but I don't think it's super
| relevant to the article: the why of a commit usually takes some
| time to explain, and the subject line is nowhere near
| sufficient, so that usually goes into the first paragraphs. For
| non-trivial commits I try to follow the "why, what, how"
| template: first explain the issue / concern / background for
| the change, then clarify the change if the diff is not super
| obvious or is a bit large, and finally explain the
| implementation changes if there were options.
|
| In my experience the former and latter are the most important
| when blame-diving, I want to know the context / driving force /
| use case for a change, but I also want to know the scope of
| consideration, because e.g. sometimes I'm thinking of a fix
| which was considered and rejected for still-valid reasons,
| while at other times it was just considered unnecessary back
| then (YAGNI) or the blockers have since been removed.
|
| Either way the subject needs to be snappy, so that it can
| quickly be selected for consideration or not e.g. if I'm blame
| diving and I see a commit which just does indenting /
| formatting, I probably can skip over it without looking at the
| actual change.
| twodave wrote:
| I mostly agree, though if I could only have "what" or "why" I
| would choose "why" every time. To me this is similar to
| describing the problem in product design. I wish the "why"
| was more often concise enough to be the prominent feature in
| a commit, because commits are difficult/annoying to amend
| (I'd be surprised if more than a couple people where I work
| knew how) and if something is going to be left out, it is the
| "why".
| masklinn wrote:
| Can't disagree with that. I think the order of importance
| is why > how > what, because the first two are the least
| likely / possible to infer from the commit contents. So an
| explicit record is most crucial.
| o11c wrote:
| > when I'm looking at blame/history
|
| Those are two very different things when it comes to commit
| messages.
|
| For history, the linked argument is arguing that subject-first
| is better. Personally I'd prefer `[component] verb details`
| though, which should fix the skippability issues mentioned
| elsewhere. And of course you can enable diffstat to get a bit
| of an idea of the structure.
|
| For blame, you have the full file context in front of you. Some
| blame frontends only show author, but assuming you have the
| commit message, what you really want out of it is a rough idea
| of the historical significance of that line. So definitely
| verbs first.
| Hamuko wrote:
| > _I actually don 't love a message that just describes the
| code change (I can figure that out on my own if I look at it
| long enough)._
|
| Isn't the point of the commit message title precisely that you
| don't have to look at it long enough?
| andai wrote:
| Spent 5 minutes trying to figure out where field_name is in the
| second list... I thought it was the same commits rewritten to be
| more scannable, but they are from a different project.
|
| (I scanned, naturally, the article itself!)
|
| Or more generally, I thought the point of the article would be
| that the function / variable names from the first list would be
| moved to the beginning of sentences. But in the 2nd example they
| are completely absent, favoring much vaguer / high level
| descriptions. So we are unable to see the before/after effect for
| the same list of commits, I think most of the potential impact of
| the author's intended point is lost.
|
| (Also, the first half extolls the virtues of being able to read
| quickly, while the second half tells you to use longer sentences
| for everything for apparently no reason?)
| r3trohack3r wrote:
| I personally prefer conventional commits.
|
| https://www.conventionalcommits.org/en/v1.0.0/
|
| The subject line says what the purpose of the change is (CI/CD,
| tests, bug fix, new feauture), what component it primarily
| focuses on, and then a plain text one line summary.
|
| For example: ci(GitLab): Add rust build
| directory to cache This should improve build
| times by caching most of the compile tree between builds. In
| testing, I've observed builds drop from 2m to 30s when scheduled
| on a node with a primed cache.
|
| It also forces me to keep my commits focused. If I can't create a
| one line summary of what I've done, it probably needs to be
| broken up into multiple commits.
| isratjahan wrote:
| I like the first concept.
| minimaul wrote:
| I like a style like:
|
| codebase section: short summary
|
| longer description if necessary
|
| eg: cocoaui: fix images being incorrectly aligned on high dpi
| displays
|
| We were calculating the position of the image in logical pixels,
| but not converting that to actual display pixels for rendering.
|
| I think it's a really nice style that makes commit messages
| really easy to scan in a short log, and lets you ignore commits
| easily that don't touch the area you're interested in
| reactordev wrote:
| I'm against any style or enforcement of style of commit messages
| that breaks _changelog_
|
| I use git log history for changelogs with a little dressing for
| markdown. I could pull this from Jira but it's worse. Stories
| aren't changes.
|
| So I understand that some folks use git log for history and care
| about their code style so much as to enforce commit message
| stylecop, it's overkill in my world and would only cause you to
| have to amend your commit or write a new message on squash.
| gherkinnn wrote:
| The subject-first style felt grating at first, but comparing the
| two I found myself reading more per line than I did in the verb-
| first approach.
|
| Fix _skip_ fix _skip_ fix _skip_ add _skip_
|
| I knew nothing at the end. The second style had me grasp more, as
| there were no obvious hooks to skip without knowing what had
| changed.
|
| But as others have said, commit messages are a cesspool of
| bikeshedding and ultimately useless, unless every commit is a
| self-contained chunk of work which it rarely is.
|
| On the side, I enjoyed all of this author's thoughts in the repo.
| Good find.
| vitus wrote:
| > The second style likely feels foreign, and possibly
| uncomfortable. It's passive voice and present tense -- all the
| things that we aren't supposed to make our commit messages.
|
| Nitpick: it's passive voice and _indicative mood_ (and sometimes
| subjunctive) -- there 's nothing wrong with present tense. "Fix
| typo" is active voice, present tense, and imperative mood. (The
| Rails commits that dip into past tense bother me slightly, but
| whatever.)
|
| Broadly, I have a few opinions on commit messages. The style
| doesn't really matter as much to me, although I'm a relatively
| strong adherent to "one-line summary, followed by paragraph(s) of
| additional context" (as is standard in the Linux kernel, and
| supposed best practice at Google even if it isn't universal by a
| long shot).
|
| One is that the commit message should be useful for anchoring a
| search for potentially relevant changes, and for providing
| broader context re: why the change was made.
|
| At the same time, I waffle between putting more description in
| the commit message, versus just commenting the code (or making
| the code clearer).
|
| The last is more pragmatic: when I'm searching for a specific
| change, I'm often looking at the history of a particular file
| (blame or otherwise). I can quickly filter out all the "fix typo"
| messages or "[LSC]" (large-scale change, term used at Google for
| various company-wide code health refactors). Or if I'm trying to
| figure out which change introduced a bug, I'll probably bisect it
| one way or another (I often try to short-circuit that bisection
| toward the end to save the last few iterations). Either way, I
| don't actually spend that much time reading through commit
| messages until I've identified a potentially problematic change.
| n_plus_1_acc wrote:
| Around half of them are actually avtive voice, like "Snapshot
| interval build argument overrides ..."
| graypegg wrote:
| Past commit messages have 2 uses to me.
|
| - Blame view, where I usually want to know the ticket number so I
| can track down a story which has the business rules the dev was
| implementing.
|
| - Bisect, where I want to know if this works or not without
| having to do a test run every time.
|
| This format is alright I guess, but the best thing you can do
| honestly is just
|
| TICKET: [done/works but wip/does not work] [describe what you're
| thinking]
|
| AB-1234: does not work, trying to rewrite this controller to
| remove all the duplication, /api removed temporarily
|
| To me, that doesn't have to be set in stone. No one likes working
| with a commit message stickler when standardized formats are only
| useful ~20 times a year to save 10 minutes each. (In my
| experience)
| vlovich123 wrote:
| The problem with the experiment is that when I'm scanning,
| typically I'm never scanning and then getting tested on the
| contents after the fact. It actually took me longer to spot any
| mention of store in the second example after being told what I
| was looking for than it did for me to find field_name after being
| told to look for it. YMMV.
| gavinhoward wrote:
| Strong disagree.
|
| Commits are actions and should place actions first.
|
| If you need to find a specific item, that is what `git log
| --grep` is for.
| turtleyacht wrote:
| Verb-first is _already_ the subject. We fill in the latter
| portion of a sentence that begins (in our head), "When merged,
| this commit will..."
| IshKebab wrote:
| I prefer the first style. It reads way less weirdly. I spend way
| more time _reading_ commit messages than "manually searching" by
| scanning them. I either arrive at the commit from git blame, or I
| use this really cool feature of computers called "ctrl-F".
| Groxx wrote:
| Ehhh... maybe. One implicit trade-off here is how low detail the
| second set is, and that'll happen any time you force a structure
| - mandated structure takes more space on average, sometimes
| significantly more. Passive voice wastes a lot of space too (in
| English anyway).
|
| Personally I think this is better solved by a changelog doc
| (which you can wordsmith _for outsiders_ , which is an entirely
| different target than internal developers) and `git blame` (I
| never _browse all of history_ to find changes to a method, just
| blame it for the latest or `git log -p -L` to check a series of
| changes to a file /func/etc).
| hn_throwaway_99 wrote:
| TBH, at least at every company I've worked at recently, the style
| of the commits is more or less irrelevant to me save for one very
| important piece: The commit starts with the ID of the ticket for
| the code change (or some placeholder for very small commits where
| a ticket wasn't necessary, e.g. [no-tix]). The biggest benefit of
| this is that these commits can then be automatically linked to
| the ticket which often has a lot more detail and conversation.
|
| 99% of the time when I'm looking at commit history, I'm not just
| generically scanning. I'm usually looking for a particular
| change, or when something touched a particular file, etc. Even
| the example given in the linked page isn't really relevant to me,
| because I'm rarely "quickly scanning" a whole commit log for
| something in particular - I'd always just use a search feature
| (in GitHub or some git IDE plugin) for that.
| kelnos wrote:
| To me, the ticket id is extra info and goes at the end of the
| message body, not in the title at all.
|
| I've seen far too many people think that putting the ticket id
| into the commit message can be a replacement for writing a good
| commit message. I've even seen people think that "Fix #123" is
| all they need to put in there.
|
| The commit history should be the primary source of truth for
| what changes have happened.
|
| I've also been at orgs where they've switched from one ticket
| tracking software to another, and haven't maintained history,
| or even when they do, the ticket ids and up changing afterward.
| geraldwhen wrote:
| Wait until corporate drops jira, or migrates prem to cloud or
| vice versa with data loss, or revokes your access to an old
| project id the app was run on.
|
| Git commit info needs to live in git. Ticketing systems will
| always die. The source remains.
| formerly_proven wrote:
| This tends to become useless after a few years because of tool
| or software migrations, changes in JIRA/whatever structure,
| ticket retention policies etc.
| cmgriffing wrote:
| I find commit messages are more useful when we consider machines
| to be primary the consumers of them.
|
| Using conventional commit style messages allow us to generate
| changelogs and modify our semver versions automatically.
| Generating changelogs by hand is extremely tedious. Modifying
| semver by hand leads to caring too much about the number.
|
| Like others have pointed out, the context and "why" can easily be
| tracked by linking out to the ticket/task that the work is
| associated with.
___________________________________________________________________
(page generated 2024-01-01 23:01 UTC)