Why would implementation details be led by product? “Undo” is an action that the user may want, which would be led by product. Not the implementation in the db.
I believe that was the point. Soft delete isn't a product requirement, it's an implementation detail, so product teams should talk about the user experience using language like "delete" or "archive" or "undo" or "customer support retrieves deleted data".
Yeah: You don't "delete" a bank account, you close it, and you don't "undo", you reopen it, etc. The processes have conditions, audit rules, attached information, side-effects, etc. In some cases the same entity can't be restored, and you have to instead create a successor.
"Undo" may work as shorthand for "whatever the best reversing actions happen to be", but as any system grows it stops being simple.
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.
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.
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:
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).
I wonder if we will trend towards a world where maintainability is just a waste of time and money, when you can just knock together a new flimsy thing quicker and cheaper than maintaining one thing over multiple iterations.
I don't think most business processes can afford to have that many issues with their code. Customers and contracts will be lost. Reputations will be lost
I don’t think that will ever be true. Let’s take a shell session as an example of ad-hoc code: People are still writing programs and scripts. Stuff doesn’t really change that often to warrant starting from scratch. Easier to add a new format to a music player than writing a new player from scratch.
reply