The real takeaway is that different projects have different requirements.
In over 30 years of using source control, I've never once worked on something where it's useful to include the component (article calls it scope) in the description in a standardised way. It's obvious what components are affected based on where in the source tree the affected files are. Similarly "bug", "fix" or "feature" adds no useful value. It's important or it wouldn't be checked in.
The only thing I've found useful, and which the article doesn't even consider, is a link / id for the relevant change request. The commit already contains all the information about what was done in the change, what's missing is the context about why.
Even on my solo projects I include a JIRA reference in square brackets before the description. If it's just something I randomly decided to fix during the course of development, I'll create a short 1 line JIRA to get an id and explain the why there.
> The only thing I've found useful, and which the article doesn't even consider, is a link / id for the relevant change request. The commit already contains all the information about what was done in the change, what's missing is the context about why.
The "why" is THE thing that needs to go in the git commit message. Capturing "why" is the entire point of that message and slapping a link to some external (and eventually absent) resource is not a good substitute.
Respectfully, I disagree. A good commit message to me is something like:
[PRJ-123] Changed blah to foo
Blah didn't handle the wangle flange properly in some cases, foo is a better fit for customer requirements.
The "why" that justifies the change, is already contained in the JIRA ticket PRJ-123 and explains exactly what the customer requirement was that necessitated the change. It will almost certainly contain a lot of detail that isn't relevant to the commit message, because that isn't the place to be documenting customer requirements, and probably relates to a number of other tickets. Perhaps the code itself might have a comment explaining the code change, if it's a non-obvious implementation, but otherwise the ticket is the best place for that information.
Additionally, if a change requires multiple commits, you don't want to be repeating the justifications for the entire feature in every commit message. It's redundant. But the commits will all be tied together by the ticket reference in the commit message.
The difference is that the Jira ticket is for everyone involved in a project (business analyst, UI designer, QA, support, DBA), while commit messages are written with developers being almost exclusive audience. PRJ-123 might explain why an end user might need it, but the commit message explains why the change (diff) is the way that it is. The ticket answers requirements-level questions, the commit message answers code-level questions. Commit messages are useful both during the review and when a future maintainer is reading the code.
> Additionally, if a change requires multiple commits, you don't want to be repeating the justifications for the entire feature in every commit message. It's redundant. But the commits will all be tied together by the ticket reference in the commit message.
Different commits do different things, so require different justifications. Here's a fictional example to demonstrate:
First commit:
[PRJ-123] Server: extract class Foo
In the next commit, we're going to need to re-use the foo logic from
class Bar. Extract new class Foo from Bar to make it available for
re-use.
Second commit on the same ticket
[PRJ-123] Server: use Foo in Baz
The users of BazClient need to be able to see foo information in the
baz dialog. Include Foo in the data sent by class Baz in the server.
Side note: the user might not even know that they are looking at Foo and Baz, it might be called something else in the UI they are shown. Whether or not this needs to be included in the commit message depends on the situation.
And later in a commit fixing a bug:
[PRJ-456] Server: check ID for null in Foo
When class Foo was extracted from Bar in commit deadbeef ([PRJ-123]
Server: extract class Foo, 2026-06-06), a null check for the field
ID got lost by accident.
Check the field ID for null in class Foo to avoid a
NullPointerException when a foo event is sent to Baz.
Hah, maybe its the difference between why as in "this addresses problem X" and why as in "because those jerks in pre-sales sold another imaginary product"
I think the commit ought to describe the purpose of the change in terms of its result for the software's intended use. Feel free to hide the business/political drama behind a ticket number.
This gets down to a more fundamental tension. Are commit messages to communicate between developers? To communicate from developer to consumer? Or some kind of project manager golem? In practice, it is usually some constantly wandering attempt to be a blend of these.
The last part is easy to answer. Commit messages are solely for developers IMHO. The communication between developer and customer / product manager should be via the ticket system.
That said, knowing the commit ID something is fixed in, so that the PM can track what build it emerges in is useful.
I find bug trackers and source control fad change several times over the life of my code. A number from a ticket system we no longer use is not helpful.
But a number from a ticket system you are using is helpful and vastly more log messages will be read during the time when it’s active than after it’s been retired/replaced.
1. Usually the commit message is often too short to capture the "why" adequately.
2. It is very beneficial to capture the why in one single source of truth, and that usually is not the Git commit message in a business context. Hate on Jira all you want, but if you capture the "why" there, you can add comments, view history, add rich context, link dependencies, add rich context, etc. Can't do that in a Git commit message.
My ire is more directed at github PRs than Jira... but the same basic idea applies. You want a single source of truth and you want that as close to the origin (the code) as possible. Your history, dependencies, etc. are all in git already and can be highlighted there if appropriate. For general comments, git notes covers that.
Business (ie. $work) will dictate whatever it wants and that is what get used but for anything I personally have control over, everything goes in the repo itself to prevent platform lock-in. For example, github's been going downhilll lately but all those projects with their history in PRs, etc. now needs to exfiltrate all that data somehow.
For GH issues you can always navigate back to the PR discussion (which should have linked issues and other pointers in it) from the commit.
Of course when we switched to GH issues, we largely abandoned JIRA and years later the instance got turned off and deleted. Now all those JIRA tags are entirely useless.
IMO that actually argues for tight coupling between your issue tracker and your git repo. And what you really want is portability (which I don't see how you get other than with tight coupling). Ideally there would be open standardized formats, but as it is, github is the 800# gorilla that defines the format and as long as gitlab and other clones can slurp in github project metadata (or at least PRs) then that effectively gets you closer.
But any way... Fixed, immutable pointers to an Atlassian product that you might not be using in 5 years is not a good policy. I'd sooner accept the policy that the git commits needed to stand entirely on their own and all the information about the "why" of the change needed to be baked into the git commit or the comments in the source (I think that fails, though, since everyone is overly terse in git commits and summarizes issues and loses information--and the back-and-forth dialog in a PR discussion is useful because it contains more than just one person's voice summarizing the reason for the change).
> Of course when we switched to GH issues, we largely abandoned JIRA and years later the instance got turned off and deleted. Now all those JIRA tags are entirely useless.
We did Bugzilla -> FogBugz -> Jira. Almost all the data was lost every time, no one bothered with migration except for the maintenance project. Worse, even on Jira we lose cases as teams end and hand off the code, and the Jira project is closed so no one else can access it.
We've also done cvs -> svn -> git. All the commits have survived migration.
I do keep including cases in the commits messages, if nothing else it'll help link things together in the future, but never rely on them for context a future maintainer might need.
> we largely abandoned JIRA and years later the instance got turned off and deleted
Sorry to be nitpicky, but why did you abandon a tool that contained a lot of valuable knowledge? That's not the fault of GH nor JIRA, that's your fault. At least you'd back up descriptions + comments from these JIRA sources.
I didn't abandon it, it was run by a different team, and we were one consumer of it. When the organization switched from Jira to GH issues the Jira was kept running for years, but nobody got the information into GH issues. Eventually the Jira was shut down, certainly by the time the company got acquired.
That isn't true though. It's very easy to export your data from JIRA. From your board, go to the List tab, filter the items to whatever you want, and then click ... and you can export the data in various different formats. Exporting as XML dumps everything.
You can trivially export your data from JIRA. If the parent experienced a situation where valuable information was lost because the instance was deactivated, that's not JIRA's fault.
It is useful if you automate generating release notes. Then your notes are grouped by new features first, then bug fixes after. This makes it a little easier for non-technical uses to read.
Absolutely not. Commit messages should never be automatically passed through to the end-customer. I also worked in a place that tried it once and it was a disaster. Sure, a list of commit messages can be a useful start as a list of things that might want to be put in the release notes, but very rarely is the developer the right person to be explaining those changes to the end user.
If a developer is being asked to do that, it's a good sign that the PM isn't doing their job properly.
Exactly. The commit message is supposed to be for the future developer, not to generate changelog.
And the main case when that developer reads the commit message is when he doesn't understand _why_ that commit exists. Not what it changes, but what is the purpose of certain lines. So he runs "blame", sees commits, the original developers are not with the company anymore, the old JIRA may not exist too, and the only hint is the commit message.
This, along with the "successful git branching model", are symptoms of the fact that devs overwhelmed with the flexibility of git and look to other people to define standards for them because they that lack the experience to do so for their own requirements.
Actually, this is also similar to classic OOP, where people use a contrived method of structuring their code.
Personally, I'm not a great fan of IPv6, but this says more about your provider than anything else.
Assuming you mean for a VPS, the majority of providers provide IPv6, and a good many would advertise your IPv6 prefix and route it to your box for a nominal fee. It's far cheaper to do anycast IPv6 than IPv4 because of the cost of IPv4 address space.
If you actually meant on-site for a business, that again depends on your provider, but again most providers should be able to give you a static IPv6 prefix from their own range if they're able to provide you a static IPv4 address. If not, you can always tunnel IPv6 to your site.
> One question I would have about the comms theory is whether the amount of power being used would be reasonable for that use-case. Jamming tends to be much higher power than just communicating, but also GNSS signals are very low bandwidth as comms channels go
GPS is suprisingly low power. I believe the satellites themselves transmit between 20W and 50W, and in general the signal is quieter than the background noise threshold. It's only by correlating with the PRNG stream [1] that the data signal can be detected at all [2].
[1] The PRNG stream is 1023 bits at 1.023Mbps, so repeats every 1ms, and only autocorrelates with the correct stream when they are aligned. When the streams are not aligned, the data looks like random noise, and each transmitter has a different LFSR configuration to provide a different sequence such that each stream has a low level of correlation with another.
[2] The PRNG stream bits at 1.023Mbps are exclusive-or'd with the data stream at 50bps, so when the decoder is using the correct PRNG and sequence offset, exclusive-or'ing with that produces detectable long pulses at the expected 50bps.
FWIW this is how almost every communication system works. They're all weaker than background noise (e.g. sunlight) but you extract them by correlating with some kind of carrier signal (often but not always a sine wave)
You do generally need a tuned filter before the rectification, unless you have an extremely large signal dominating the local airwaves. Which is precisely the parent poster's point: with RF you are almost always doing something to demodulate the signal. Whether you are doing it with a sine wave or something more complicated is not that fundamentally different. (and if you're looking at a spectrum analysis, that is looking at the radio signal from the point of view of that sinusoidal modulation scheme, so you will see such signals 'above' the noise floor more readily than something using a different modulation).
Firstly, I think 0.15% might be significantly lowballing. Other commenters I've read trying to low ball it suggested 0.5%, which matches up with my calculations - this IPO is allegedly $1.5T on the total amount, and 25% is up for sale, making $375B. The S&P 500 market cap is $69T, which puts the IPO at 0.54%.
In addition, that's just the initial IPO free float value, and other shareholders will be free to shed their shares after IPO (and presumably, that's where the bulk of index investment funds will actually buy from), so the free float will be higher, pushing up that share even higher.
Sure, in terms of overall market fluctuations, 0.5% is significantly less than a typical day of market volatility, but on the other hand in terms of my current portfolio, as a dollar amount that's significantly more than my monthly expenditure when I'm not vacationing. I don't particularly want to be funding Elon's exit strategy when I already believe it to be a scam. Thanks to S&P's decision, about 25% of my investments are safe, but approximately 60% of my funds are linked to FTSE World indicies, which is changing the rules.
As I stated in another post, this is just a cheap stunt to force passive investors to prop up the price before it has a chance to settle. The majority of IPOs settle on a price below the IPO price in the months afterwards, and never before have we seen an IPO with such a high P/E ratio. This is literally unprecedented, and the sensible thing to do would be to stick to the old rules to allow the market time to discover the true value before inclusion in the indices. At the moment, the valuation is just a number in Elon's head rather than a fair market valuation. Forcing index-following funds to purchase it at the artificially high price is reckless at best and profiteering at worst.
In addition, it's not just 0.5%. It's 0.5% now, and then the same for Anthropic, and then the same for OpenAI, then all the other IPOs in the future. To put that into perspective, most investors would baulk at 0.38% TER for a passive fund and move to 0.12% TER. 0.5% isn't nothing.
That would be true IF the stock was already being traded.
All we have at the moment is just Elon saying "I think this is worth $1.5T, convincing a small subset of people to buy shares, and then because of this change, market following funds will be forced to pile in before the market has had time to discover the actual true fair price, thus artificially propping up the price until Elon has had time to unload a load more shares. The rule changes serve only Elon, not regular investors.
Historically, the share price falls sharply after an IPO in the vast majority of cases. In this case, with the asking price masssively over earnings, significantly more than any other company, it should be expected that the price will fall significantly in the weeks after IPO.
Shortening the window before it gets included in the index is a cheap trick to force passive investors to pile in at the inflated prices, in an attempt to artificially boost demand and prop up the share price.
If the company genuinely was worth the valuation being asked for in the IPO, they would have no problems with just waiting a few months before it would be included under the existing rules.
I have smart features on and use the web interface and am still not seeing the annoying stuff! Maybe I'm not cool enough. Or it's figured I'm not into it.
Not sure if you're talking about cron or systemd, but cron definitely has that in /etc/cron.d where you can have arbitrary crontabs, or /etc/cron.{hourly|daily|weekly|monthly} where you can just place arbitrary scripts if you don't care exactly when they run, just the frequency.
The more likely risk with a 6845 is creating a way out of spec vertical sync that can cause the monitor's frame flyback transformer to fail. Although how you describe the PET monitor's beam being "parked" suggests it's actually the same effect.
I recall seeing it just stop dead center, quite bright. Immediately just turned the machine off, but that did seem to account for why a couple of the other machines in the room had small round-ish phosphors burns right in that spot
FWIW there's a good chance your fridge does more than that without you realising it if it's a fridge freezer. A lot of fridge freezers now have an anti-frost system that about once a week or so actually heats up the freezer so that any accumulated ice can melt, and then presumably blows out the damp air somehow (not entirely sure how that part works, other than just blowing the air up the the fridge and hoping the air there is dryer than the air in the freezer) and then goes back to regular freezer mode. I deliberately just an old-school fridge-freezer because having this defrost mode reduces the time you can safely leave things in the freezer for.
In over 30 years of using source control, I've never once worked on something where it's useful to include the component (article calls it scope) in the description in a standardised way. It's obvious what components are affected based on where in the source tree the affected files are. Similarly "bug", "fix" or "feature" adds no useful value. It's important or it wouldn't be checked in.
The only thing I've found useful, and which the article doesn't even consider, is a link / id for the relevant change request. The commit already contains all the information about what was done in the change, what's missing is the context about why.
Even on my solo projects I include a JIRA reference in square brackets before the description. If it's just something I randomly decided to fix during the course of development, I'll create a short 1 line JIRA to get an id and explain the why there.
reply