Point #2 is very true for me. I get concerned when I look at a project and see thousands of issues. For safety and to not waste my time, if I see that and the project is an unknown to me, I just have to believe that it indicates the project is not being maintained properly.

I definitely think splitting discussion and issues is a good idea for that reason alone.

I usually try to scan the issues and look at a few, to get a vibe of what the makeup of that number is. It can be really attractive to try to just compare project metrics like that, though.

And Start11 (which can integrate with Everything!)

Even if you try to get them to not, they will still overcomment the code. Or at least overcomment it from the perspective of a human. From the perspective of the LLM, I suspect the comments are necessary for it to be able to get the code output correct.

It's also a discoverability tool. If the code has good docstrings and decent naming for functions/variables it's a lot easier for the LLM to find the correct places to edit.

Seems like a sensible way to archive branches. It's not like a tag and branch are actually very different anyway, right? A tag is a pointer that always refers to the same commit while a branch is a pointer that follows commits forward. And for something that's archived, you don't need the pointer updating mechanism.

> A tag is a pointer that always refers to the same commit

It's not guaranteed not to change. The UI just makes it harder to update.

And anyone whose coworkers replace tags on a regular basis will be familiar with the following message from git when pulling changes:

would clobber existing tag

Really wish my coworkers would leave old tags as they were heh.

I have a somewhat different use case, where a work project has a moving "latest" tag. I discovered then the --force param with git fetch --tag

A hook should be able to prevent that

Hooks only keep honest people honest :) and an LLM will happily clobber a tag and skip hooks while the user just spams “accept”.

I dont find the idea of a immutable "descriptive" tag or branch to be that useful (I also dont find the differentiation of tags and branches to be useful either) I've seen plenty of repositories where tags end up being pretty ambiguous compared to each other or where "release-20xx" does not actually point to the official 20xx release. Immutable references are more typically handled by builders and lockfiles to which Git already has a superior immutable reference system, the commit hash.

I 100% agree on the latter (the tag != release is more of a project management issue), and the same concept applies to containers and their digest hashes. The main issue at the end of the day is the human one: most people don't like looking at hashes, nor do they provide context of progression. I would say "give both" and make sure they match on the end user side of things, but tags are the most common way (open source) software releases are denoted.

As long as we can create and delete tags, they will never be immutable, right?

The purpose of the forge is to be able to prevent this. Protected tags are usually a feature which provides a way to mark tags as untouchable, so removal would require a minimum level of trust to the repository on the platform. Otherwise, attempts to push tag deletions or changes for tags matching the protected pattern would be rejected/ignored.

Of course, the repository owner has unlimited privilege here, hence the last part of my prior comment.

Tags are just a text file with a name and the sha of the tag object (with the commit and some metadata/signatures as contents), last I checked. It's deliberately simple and thus almost impossible to actually lock it down in concrete terms.

Packed refs are a little more complicated but all of the storage formats in git are trivial to manually edit or write a tool to handle, in extremis.

That's the purpose of the forge platform, to provide a way to prevent changes to these files from being accept into the source repository. For example:

https://docs.github.com/en/repositories/configuring-branches...

https://docs.gitlab.com/user/project/protected_tags/

https://forgejo.org/docs/latest/user/protection/#protected-t...

Can't solve culture problems with technology, but we all know that by now, right?

That's true for local hooks, but neither a dishonest person nor an LLM can bypass a pre-receive hook on the server (as long as they don't have admin access).

Thanks, apparently most people here aren't familiar with server-side hooks.

Correct.

One is refs/heads/<name> and the other is refs/tags/<name>

Branches are expected to change. When a commit is authored, HEAD (the current branch) updates to that commit.

Tags are expected not to change (though they can).

Other difference (actually, more like a consequence of what you said) is that Git keeps reflogs for branches but not for tags

I really hate that by default all of these tools perform completion with tab. It makes it very difficult to add indentation. It's not a problem with traditional autocomplete because you either need to already have a character typed before the cursor, or to have manually summoned the completions. But these AI autocompletes will try to generate code on completely empty lines, so you think you're pressing tab to get an indent and instead end up with code you did not want.

Also install the GNU coreutils (or I guess uutils). If you're begrudgingly using macOS then you're going to hate the differences between BSD and GNU utilities.

I probably should have returned mine. I still love the idea of the device, but the speakers, display, and trackpad are subpar. I get that I'm spoiled by the quality of a MacBook Pro in those areas, but they still feel worse than other laptops I've tried.

Also he says he's never heard the fans spin up but I've had the system spin the fans up very high and they get loud. And the spin-up was definitely valid the times when I checked because the device was extremely hot, I think from charging.

Now the laptop is being used as a server. Ended up being good for Jellyfin because I can have the GPU handle transcoding and tonemapping of 4K HDR movies.

Would be cool if Framework would sell speakers, a display, trackpad and housing comparable in quality to a MacBook Pro. It would have a high pricetag but you could slowly upgrade your machine. Especially since swapping out speakers or a trackpad is so easy.

Right now the Laptop 13 speaker kit is €20 but they could offer a €150 option that performs similar to a MacBook Pro for people who value sound.

It's not only a matter of having better hardware (though it certainly helps a lot). For example, Apple does a lot of software tuning and tweaking to make the Macbook speakers sound as good as they do. And it's been fascinating to read the extent of work Asahi Linux had to do to recreate the software portion of Macbook's audio stack.

https://asahilinux.org/docs/sw/audio-userspace/ https://github.com/AsahiLinux/asahi-audio

The problem is you need correction EQ built into to the drivers tuned to the enclosure (in addition to loudspeakers that are also designed accounting for their directionality, position, and the volume of the enclosure).

you also need a lid angle sensor instead of a open/closed detector to account for the acoustic reflections off of the screen

They should be able to offer a better trackpad module (and I've been hoping that they eventually do). The speakers seem like a harder problem to solve. The acoustic engineering that goes into designing a good speaker involves every element that can interact with the sound waves, not just the driver itself.

I noticed my most recent nitpick comment got a significant number of upvotes. I spent some time today wondering if HN needed a way to indicate something is a nitpick and cause the votes on it to carry less weight in the sorting. Because if the nitpick is valid I don't think downvotes are appropriate since people might end up seeing it and having misconceptions corrected, but it also shouldn't detract from discussions on the meat of the post.

Of course I'm probably the odd one out, wanting to apply that modifier to my own nitpick comments, so that idea probably wouldn't end up being very useful in general.

(There is also some irony in me commenting on your comment here where it's completely unrelated to the actual post...)

Nitpick: UTC stands for Coordinated Universal Time. The ordering of the letters was chosen to not match the English or the French names so neither language got preference.

Universal Time, Coordinated.

This is how I say it in my head.

Now every time I see UTC, I hear the voice of Yoda: "Universal Time, Coordinated it is."

That doesn't quite match what the wikipedia page says:

> The official abbreviation for Coordinated Universal Time is UTC. This abbreviation comes as a result of the International Telecommunication Union and the International Astronomical Union wanting to use the same abbreviation in all languages. The compromise that emerged was UTC, which conforms to the pattern for the abbreviations of the variants of Universal Time (UT0, UT1, UT2, UT1R, etc.).

Follow the citation: https://www.nist.gov/pml/time-and-frequency-division/how-utc...

> ... in English the abbreviation for coordinated universal time would be CUT, while in French the abbreviation for "temps universel coordonné" would be TUC. To avoid appearing to favor any particular language, the abbreviation UTC was selected.

It's also the time in Iceland, conveniently

That's an interesting rationale.

Reminds me of when a group is divided into two parts, dubbed group 1 and group A, such that neither feels secondary.

And if you have 3, group 1, group A, and group Alpha. Beyond that, just use colors.

The trick is making sure no one is happy with the final outcome

It also stands for Universel Temps Coordonné.

It's le temps universel coordonné in French.

No I won't be happy about it, but yes if I block emergency services and they need to damage my property then I am absolutely the one who should have to pay.