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?
