Re: [Idea] Only allow commits when no undeletable file has been deleted

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 2536 bytes --]

On 2024-03-15 at 18:55:37, leon wrote:
> Hello,
> 
> I have an idea for a feature I am missing often enough within Git (and it
> **needs** to be part of Git itself as it would be rather useless within
> third-party tools):
> Oftentimes, when you have submodules, you are depending on specific files
> being present within them, i.e. so that your Shell scripts and/or CI tools
> work correctly.
> However, especially when the submodule is under your own control, you
> currently have no option to tell future collaborators that deleting or
> renaming such a file will break things.
> Or even your future self, FWIW.
> So, what if there was a recognized attribute within the `.gitattributes`
> that said `files matching this path spec cannot be deleted`?
> The actual content of the file is irrelevant as long as it exists.
> I don't care how this attribute is called in the end and cannot think of any
> good name.
> My best approach was something like `depended-on-externally` or
> `undeletable`.

I think you want something more than "undeletable".  If I change your
`script/build` file to contain only "Kilroy was here", it's still not
going to work, since that's neither a valid script nor a valid
executable.  I certainly haven't deleted it, but I've rendered it
unusable nonetheless.  This sounds like a contrived example, but it's
entirely possible for people to typo a filename using completion and
save the wrong thing to the wrong file or redirect the output of a
program to the wrong place accidentally.  We've all done it.

I think this is a great place for a CI job, though.  If you know these
files are required, you can add a cheap CI job that simply checks to see
whether the files are valid scripts (or whatever policy you'd like to
have) and fails early on.  You can even make other CI jobs depend on it
so that you don't waste a lot of time failing all the other CI jobs when
their files are missing.

One thing I've also seen that we have at work is that you can link CI
jobs for project A to project B.  Thus, if project B is a dependency of
project A, changes to project B run its own CI jobs plus a standard
project A CI job, to verify that nothing's broken.  This is really
useful and a great way to avoid breaking things in more subtle ways
(e.g., removing a function that you didn't think you needed, but project
A does, or changing the behaviour of a function in a way that breaks
other projects).
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]