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

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

[leon]

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`.

My proposed behavior is thus the following:
- Git stores the list of files from HEAD that may not be deleted somehow 
(probably best to compute it on the fly when necessary)
     - To allow for deleting a file in the same commit as removing its 
`.gitattribute` entry, the list of files that cannot be deleted depends 
on the `.gitattributes` as it should be committed.
- When you try to create a commit, all undeletable files are checked for 
if they still appear in the tree
- If files are no longer present in the tree, the commit is aborted with 
an error message telling the user something like `You are trying to 
delete the undeletable file <x>/ files <x, y, z>. Either restore 
it/them, or remove <corresponding path specs> from the '.gitattributes'`
- In particular, this means the following behavior for changes:
     - Adding a new file: Nothing to do
     - Deleted file: Checking if it can actually be deleted
     - Renamed file: Checking if another file replaced it
- No idea how to handle path specs pointing inside submodules. I'm fine 
either way:
     - Path specs going into submodules are ignored (more performant, 
plus you cannot influence them directly)
     - Path specs going into submodules are checked too (helps catch 
bugs early as an error can only happen when you update the submodule. As 
such, you'll quickly know that you just broke something)

Drawbacks of this approach:
- `git commit` will be slower. Don't know how much, probably depends on 
the implementation

Advantages:
- You can ensure that you don't accidentally break something in other 
repos (or even your own, if you have enough dependencies on your own 
filenames…)

So, what do you think?

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

[brian m. carlson]

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