>"git status" needs to be clean. I don't want to see any untracked temporary files.
Why do you not want to see any untracked files? What harm does it cause? What is the problem that you are trying to solve?
> If it's untracked either it needs to be ignored or it's a new source file to add to the index.
Or it is a file that stores your notes or experiments that don't necessarily belong in a branch, do not want to include in your next commit, but you also don't want to be invisible to ".gitignore" aware tools - and increasingly many modern tools are (vscode, ripgrep, emacs's projectile to name a few).
>Keeping untracked files lying around not gitignored is a recipe for one day committing one by mistake, or conversely, that some of them are source files you've forgot to commit.
Neither of those are a factor if you consciously check what you are committing using "git status" and "git diff --cached".
This is the habit you want to inculcate in your junior developers, that they should consciously think about the commit they are sending for code review, not that they should meticulously manage and be completely dependent on .gitignore (and i presume you also mean .git/info/exclude - because of course they would also have local files that they don't want to commit but are not worthy of being put into the repo's .gitignore).
Why do you not want to see any untracked files? What harm does it cause? What is the problem that you are trying to solve?
> If it's untracked either it needs to be ignored or it's a new source file to add to the index.
Or it is a file that stores your notes or experiments that don't necessarily belong in a branch, do not want to include in your next commit, but you also don't want to be invisible to ".gitignore" aware tools - and increasingly many modern tools are (vscode, ripgrep, emacs's projectile to name a few).
>Keeping untracked files lying around not gitignored is a recipe for one day committing one by mistake, or conversely, that some of them are source files you've forgot to commit.
Neither of those are a factor if you consciously check what you are committing using "git status" and "git diff --cached".
This is the habit you want to inculcate in your junior developers, that they should consciously think about the commit they are sending for code review, not that they should meticulously manage and be completely dependent on .gitignore (and i presume you also mean .git/info/exclude - because of course they would also have local files that they don't want to commit but are not worthy of being put into the repo's .gitignore).