[ziml77]

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]

> 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_]

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.

[az09mugen]

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

[toenail]

A hook should be able to prevent that

[monkpit]

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

[mroche]

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]

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.

[Buttons840]

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

[jaggederest]

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.

[venturecruelty]

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

[Denvercoder9]

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]

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

[paulddraper]

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]

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