They are implemented in a maximally safe way, which generally means they leave files / folders / etc lying around when you least expect it which goes on to caus

They are implemented in a maximally safe way, which generally means they leave files / folders / etc lying around when you least expect it which goes on to cause later annoyances, because doing otherwise could mean deleting data you didn't know would be deleted. Say you're git, and someone has a submodule that goes from having: sub/ .gitignore = a/ignored.txt a/ tracked.txt ignored.txt to this, when they `git checkout` some other newer or older or totally-separate-history branch (possibly several layers above this submodule): sub/ b/ tracked.txt what do you do with sub/a/ignored.txt? What if the whole submodule was removed? Git's answer to every single question like this is to either fail to perform the submodule version change, or leave a now-untracked-and-not-ignored sub/a/ignored.txt file in the directory, which leaves you with an un-clean checkout that it'll warn and complain and possibly conflict on. It's highly unergonomic, but reliably avoids silently doing anything that might cause you to lose data. The awful ergonomics are what people generally hate about it. They'd rather it made some consistent decisions so it Just Worked™ in nearly all cases. But that's not Git-like.