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:
signature.asc
Description: PGP signature
