HN user

andrybak

136 karma

https://andrybak.dev

Posts2
Comments33
View on HN

Articles for Deletion votes -- original with comments

Summarizing it, 5/7 for delete have accounts, and 1/4 for keep have accounts. Not along after the final vote, a Wikipedia admin deleted the article. Being a little bit lax with my language, the majority's consensus agreed that Odin isn't notable, and the article had no reliable sources.

important clarification about a popular misconception: "Articles for deletion" discussions on English Wikipedia are not decided by vote.

For more details, see

- https://en.wikipedia.org/wiki/Wikipedia:Polling_is_not_a_sub...

- https://en.wikipedia.org/wiki/Wikipedia:Guide_to_deletion#Ov...

Git is more robust than Jira. Git log is accessible offline. Jira descriptions exist only as long as people managing the Jira instance are competent and are migrating the necessary data correctly when migrations are needed. Even migrations from one Jira instance to another (e.g. when companies get acquired and two Jira servers get merged) can be extremely brittle.

It's fair that maybe such simple trivial changes don't deserve such a wordy commit message. But these are just fictional examples that I came up with on the spot. Refactorings, new features, and bugfixes can all have various levels of complexity.

A good commit message helps answer the "why?" questions first and foremost. If a diff is fairly large, pointing out the most important change can be useful. Explanations for non-trivial dataflow can sometimes not make sense in separate documentation, but still be relevant in a commit message.

if IDE supports converting them into clickable links, then scrolling through a log in its Git integration (kinda like `git log --oneline`) will be a convenient list of links to issues. If the commit messages are good, you just skip over the Jira issue/ticket key/ID. If what you want is to see the requirements of a feature or steps to reproduce of a bug or some other context for the ticket, then a clickable link is very convenient. Of course, sometimes it does make sense to include some of that information in the commit message as well.

When working in big teams, it can be very hard to increase the usefulness of commit messages. On the other hand, enforcing inclusion of a Jira issue key in commit messages is easy to implement. Relying on issue tracker descriptions can be a difficult proposition as well. Quality of individual ticket descriptions can be low; depending on how responsibility for maintenance is handled, the bug tracker migrations can sometimes be handled improperly and information can be more easily lost than in a Git log.

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.

According to the original reporter, the bug is still exploitable and that's why the issue on the bug tracker got hidden again.

OH NO I JUST REALIZED THIS IS NOT ACTUALLY PROPERLY FIXED AND STILL WORKS

even worse, edge no longer even makes the download menu pop up, so it's completely silent js rce that keeps running even after you close the browser !!

all from just visiting a single website once !!

issue set to private again, hopefully it'll get fixed properly this time :p

In this second test, the word error rate was 43.75 percent, meaning participants identified a bit more than half of the recorded words correctly.

[...]

“We’re not at the point where it could be used in open-ended conversations. I think of this as a proof of concept,” [Sergey Stavisky, a neuroscientist at UC Davis and a senior author of the study] says.

The ability to produce sound without a use of a dictionary sounds awesome. It is an interesting result, a proof of concept as the author of the study says, but the title is editorialized at best and effectively clickbait at worst, because most readers will assume that "near instantaneous speech" means "clear intelligible speech and ability to communicate".

One thing that put me off is how so much of what I saw was just talking about Bluesky vs Twitter. I hope they can move past that.

Judiciously using the muting features is required to have a good time in social media. Add "Twitter" to muted words to move past that on your own.

I put the symbol on my shell prompt line, when there's a readme file found in the current directory. Just a reminder, especially for directories, in which I'd put the readme file myself, but then forgot about it.

https://github.com/rybak/scripts/blob/master/config/ps1_noti...

It works together with very dumb script in $PATH, which prints a readme file if one is found in the current directory.

https://github.com/rybak/scripts/blob/master/commands/readme

which branch on a remote is considered the default

You probably mean this place in code: [1]. It uses function git_default_branch_name from refs.c [2], which uses config variable `init.defaultBranch` I've mentioned above. But if it and other look-ups fail, it does fall back to a hard-coded "refs/heads/master".

[1] https://github.com/git/git/blob/v2.43.0/remote.c#L2380-L2394

[2] https://github.com/git/git/blob/v2.43.0/refs.c#L671-L705

Edit: removed mention of a deprecated Git feature to avoid confusion.

You couldn't model Rust's `Option` or `Result` as a java enum.

For reference, they can be modeled as a "sealed" class since Java 17. https://openjdk.org/jeps/409

Prior to Java 17, sealed classes feature can be partially recreated via private constructors in the super classes. This approach forces you to put all classes in a single Java file, which can be awkward to navigate.

Git doesn't have the concept of "main is special"

Technically, there is special handling for both "master" and "main" in Git in fairly obvious, but I'd argue in a not very important way. When you merge two regular branches, the commit message is `Merge branch 'source' into destination`. But not if destination is `master` or `main` – the `into ...` part is omitted for those merge commits.

But this is just for backward compatibility. Git is very conservative in changing such user facing behavior as generated merge commit messages. To get Git to treat `master` and `main` truly without special handling, set empty value to config option `merge.suppressDest` [1]:

    $ git config merge.suppressDest ""
`master` is also used as the default name for the default branch in newly created repositories. See option `--initial-branch` of `git init` and config variable `init.defaultBranch` [2] to override. Git for Windows, for example, allows setting the config option in its installer.

Source code:

For merge commit formatting: https://github.com/git/git/blob/2108fe4a1976f95821e13503fd33...

For default branch naming: https://github.com/git/git/blob/91e2ab1587d8ee18e3d2978f2b7b...

Git for Windows installer suggesting setting `init.defaultBranch`:

- https://github.com/git-for-windows/build-extra/blob/586c46ec...

- https://github.com/git-for-windows/build-extra/blob/586c46ec...

Footnotes:

[1] https://git-scm.com/docs/git-merge#Documentation/git-merge.t...

[2] https://git-scm.com/docs/git-init#Documentation/git-init.txt...