frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

fp.

Start all of your commands with a comma (2009)

https://rhodesmill.org/brandon/2009/commands-with-comma/
250•theblazehen•2d ago•84 comments

Hoot: Scheme on WebAssembly

https://www.spritely.institute/hoot/
23•AlexeyBrin•1h ago•1 comments

OpenCiv3: Open-source, cross-platform reimagining of Civilization III

https://openciv3.org/
705•klaussilveira•15h ago•206 comments

The Waymo World Model

https://waymo.com/blog/2026/02/the-waymo-world-model-a-new-frontier-for-autonomous-driving-simula...
967•xnx•21h ago•558 comments

Vocal Guide – belt sing without killing yourself

https://jesperordrup.github.io/vocal-guide/
66•jesperordrup•6h ago•28 comments

Reinforcement Learning from Human Feedback

https://arxiv.org/abs/2504.12501
7•onurkanbkrc•43m ago•0 comments

Making geo joins faster with H3 indexes

https://floedb.ai/blog/how-we-made-geo-joins-400-faster-with-h3-indexes
135•matheusalmeida•2d ago•35 comments

Where did all the starships go?

https://www.datawrapper.de/blog/science-fiction-decline
42•speckx•4d ago•34 comments

Unseen Footage of Atari Battlezone Arcade Cabinet Production

https://arcadeblogger.com/2026/02/02/unseen-footage-of-atari-battlezone-cabinet-production/
68•videotopia•4d ago•6 comments

ga68, the GNU Algol 68 Compiler – FOSDEM 2026 [video]

https://fosdem.org/2026/schedule/event/PEXRTN-ga68-intro/
13•matt_d•3d ago•2 comments

Jeffrey Snover: "Welcome to the Room"

https://www.jsnover.com/blog/2026/02/01/welcome-to-the-room/
39•kaonwarb•3d ago•30 comments

What Is Ruliology?

https://writings.stephenwolfram.com/2026/01/what-is-ruliology/
45•helloplanets•4d ago•46 comments

Show HN: Look Ma, No Linux: Shell, App Installer, Vi, Cc on ESP32-S3 / BreezyBox

https://github.com/valdanylchuk/breezydemo
237•isitcontent•16h ago•26 comments

Monty: A minimal, secure Python interpreter written in Rust for use by AI

https://github.com/pydantic/monty
237•dmpetrov•16h ago•126 comments

Show HN: I spent 4 years building a UI design tool with only the features I use

https://vecti.com
340•vecti•18h ago•147 comments

Hackers (1995) Animated Experience

https://hackers-1995.vercel.app/
506•todsacerdoti•23h ago•247 comments

Sheldon Brown's Bicycle Technical Info

https://www.sheldonbrown.com/
389•ostacke•21h ago•97 comments

Show HN: If you lose your memory, how to regain access to your computer?

https://eljojo.github.io/rememory/
303•eljojo•18h ago•188 comments

Microsoft open-sources LiteBox, a security-focused library OS

https://github.com/microsoft/litebox
361•aktau•22h ago•186 comments

Cross-Region MSK Replication: K2K vs. MirrorMaker2

https://medium.com/lensesio/cross-region-msk-replication-a-comprehensive-performance-comparison-o...
3•andmarios•4d ago•1 comments

An Update on Heroku

https://www.heroku.com/blog/an-update-on-heroku/
428•lstoll•22h ago•284 comments

PC Floppy Copy Protection: Vault Prolok

https://martypc.blogspot.com/2024/09/pc-floppy-copy-protection-vault-prolok.html
71•kmm•5d ago•10 comments

Was Benoit Mandelbrot a hedgehog or a fox?

https://arxiv.org/abs/2602.01122
23•bikenaga•3d ago•11 comments

The AI boom is causing shortages everywhere else

https://www.washingtonpost.com/technology/2026/02/07/ai-spending-economy-shortages/
25•1vuio0pswjnm7•2h ago•14 comments

Dark Alley Mathematics

https://blog.szczepan.org/blog/three-points/
96•quibono•4d ago•22 comments

How to effectively write quality code with AI

https://heidenstedt.org/posts/2026/how-to-effectively-write-quality-code-with-ai/
270•i5heu•18h ago•219 comments

Delimited Continuations vs. Lwt for Threads

https://mirageos.org/blog/delimcc-vs-lwt
34•romes•4d ago•3 comments

I now assume that all ads on Apple news are scams

https://kirkville.com/i-now-assume-that-all-ads-on-apple-news-are-scams/
1079•cdrnsf•1d ago•461 comments

Introducing the Developer Knowledge API and MCP Server

https://developers.googleblog.com/introducing-the-developer-knowledge-api-and-mcp-server/
64•gfortaine•13h ago•30 comments

Understanding Neural Network, Visually

https://visualrambling.space/neural-network/
305•surprisetalk•3d ago•44 comments
Open in hackernews

Archiving Git branches as tags

https://etc.octavore.com/2025/12/archiving-git-branches-as-tags/
134•octavore•1mo ago

Comments

ziml77•1mo ago
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.
progval•1mo ago
> 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.

QuantumNomad_•1mo ago
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.

toenail•1mo ago
A hook should be able to prevent that
monkpit•1mo ago
Hooks only keep honest people honest :) and an LLM will happily clobber a tag and skip hooks while the user just spams “accept”.
mroche•1mo ago
Luckily commonly used forges for collaboration have the ability to make tags immutable. Any repository where multiple people collaborate on a project should have that feature enabled by default. I'm still waiting for the day where tags are immutable by default with no option exposed to change it.

I'm sure that would cause problems for some, but transitive labels already exist in Git: branches.

MadnessASAP•1mo ago
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.
mroche•1mo ago
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.
Buttons840•1mo ago
As long as we can create and delete tags, they will never be immutable, right?
mroche•1mo ago
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.

jaggederest•1mo ago
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.

mroche•1mo ago
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...

Denvercoder9•1mo ago
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).
toenail•1mo ago
Thanks, apparently most people here aren't familiar with server-side hooks.
venturecruelty•1mo ago
Can't solve culture problems with technology, but we all know that by now, right?
az09mugen•1mo ago
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
paulddraper•1mo ago
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).

lucasoshiro•1mo ago
Other difference (actually, more like a consequence of what you said) is that Git keeps reflogs for branches but not for tags
PunchyHamster•1mo ago
How often did you go back to the archived tagches that are older than say, 6 months ? Seems very niche, unless dunno, there are no version tags in the repo.
yawaramin•1mo ago
True. At work our flow is to tag commits that we want to mark as release candidates and delete feature branches after their PRs are merged/declined. We've never had a need to archive branches.
phire•1mo ago
It seems very useful for archiving branches that never got merged.

Sometimes I work on a feature, and it doesn’t quite work out for some reason or another. The branch will probably never get merged, but it’s still useful for reference later when I want to see what didn’t work when taking a second attempt.

Currently, those abandoned branches have been polluting my branch list. In the past I have cloned the repo a second time just to “archive” them. Tags seem like a better idea.

dotancohen•1mo ago
I sometimes leave merged branches around for quite a while, because I squash them when I merge to master and sometimes when tracking down a bug the ability to bisect very handy.
matijsvzuijlen•1mo ago
What made you decide to squash when merging instead of leaving the commits in the history so you can always bisect?
quesera•1mo ago
Not GP, but we do the same. Branches become the atomic unit of bisection in master, but the need is extremely rare. I think because we have good tests.

We also keep merged branches around. This has never happened, but if we needed to bisect at the merged-branch level, we could do that.

I know squash-merge isn't everyone's cup of tea, but I find it to be simpler and clearer for the 99+% case, and only slightly less convenient for the remainder.

dotancohen•1mo ago
The range reason your history textbook is not infinitely long. The longer something is, the less digestible. When we need more granularity, it's there in the branches.
skydhash•1mo ago
I don’t think I’ve ever returned to a branch that I can easily rebase on top of the main branch. And if I really wanted to, I’d prefer to extract a patch so that I can copy the interesting lines.

Any branch older than 6 months is a strong candidate for deletion.

ervine•1mo ago
Wonder if it's worth squashing in the branch, merging to main, then immediately reverting.

Now the work is visible in history, branch can be deleted, and anyone in the future can search the ticket number or whatever if your commit messages are useful.

Dunno if it's worth polluting history, just thinking out loud.

PunchyHamster•1mo ago
let it go. You will not bother fixing those to work with master.

It just moves trash from branch list to tag list.

fragmede•1mo ago
if you're deleting branches then why would you need to archive them? What would you even archive if you're deleting them? My deeper question is why are you deleting them in the first place though?
yawaramin•1mo ago
We're deleting them because we don't need them and we like keeping things tidy.
venturecruelty•1mo ago
Believe it or not, some people need to use software more than six months old.
tonymet•1mo ago
IMO a cleaner way to do this is with a headless remote, either on disk or “backed up” on a server. `git push —-all` won’t delete refs on the remote, so you don’t have to do any additional work to record or recover them.

`git push —all backup` will record all of your refs and tags

If you are archiving branches in your own rep, prefix with `ar/` so you can grep -v to conceal them.

See also `git notes` to record metadata an against a commit without changing the commit

derriz•1mo ago
> Important note: the strange magic requires the official git completion script.

I dislike the official git completion script because it’s so slow when working with large repos. On macOS - because of vagaries of the way its file system works - with large repos it’s effectively unusable. Hint to completion script writers: if your “smart” completion ever takes seconds, it’s worse than useless and far worse than “dumb” filename completion.

AdieuToLogic•1mo ago
On a related note, git supports incorporating custom commands via executables available in the `PATH` having the naming convention of:

  git-<command name>
Where "command name" in this case would be `archive-branch` and could be defined thusly:

  #!/bin/sh
  # git-archive-branch

  git_branch="${1:-$(git branch --show-current)}"

  git co main &&
    git tag archive/$git_branch $git_branch &&
    git branch -D $git_branch
It then could be invoked the same as the alias:

  git archive-branch ...
rurban•1mo ago
Oh oh. Your co alias leaked :)
cyco130•1mo ago
Not the gp but I can't live without co/ci/br now.
rurban•1mo ago
Sure. I cannot imagine anyone living without the most common aliases anymore, but in a script you either need to alias again, or expand. Happens so often to me also.
vbezhenar•1mo ago
Why is this useful? Why would someone care about typing `git archive-branch` instead of `git-archive-branch`?
kreetx•1mo ago
Consistency: not needing to remember under which alternative methods any command was found under.
kazinator•1mo ago
I don't see the point of this. A git branch is already a kind of tag.

How about just

  # rename branch to archive/ prefix to indicate it is archived
  git branch -m foo-branch archive/foo-branch
figmert•1mo ago
Branches are expected to change, tags are not. Tags are also mildly harder to change. A tag seems more apt for an archived branch. So I sort of see where OP comes from.
Zardoz84•1mo ago
Yeah. But WHY taging instead of renaming the branch ? I don't say if it is a good or bad idea. But I would like to know why.
rolandog•1mo ago
If you read the article, it credits a reddit thread as the source of inspiration; the thread ultimately points to a StackOverflow answer [0] which may offer a better argument as to why they liked yo use this pattern.

[0]: https://stackoverflow.com/a/1309934

cachvico•1mo ago
You can accidentally push to a branch. You can't accidentally push to a tag.
MaulingMonkey•1mo ago
FWIW, this is what I do, although typically with the prefix `dead/`, unto which I abandon ideas and misdirected refactoring with reckless abandon.
kjksf•1mo ago
Because in git tooling (be it github.com or a tui/gui client like lazygit), git branches are shown more prominently because the expectation is that a branch is something you actively work on (if you're finished with a branch, you delete it).

If you don't anticipate working on a branch but you want to preserve the code you leave it but it starts to clutter that prominent "active" space in most git tools.

This allows you to preserve the code (if you ever want to look at it again) while also de-cluttering the prominent "branches" view.

kazinator•1mo ago
How would this argument change if git branch recognized the "archive/" convention, or had some other mechanism, such that archived branches are concealed from view unless -a/--all is given?

I like the idea that branch names starting with . (period) are considered hidden, similarly to files in Unix.