git add . будет искать в текущем каталоге и подкаталогах файлы, которые можно добавить, и затем их добавить.
git add -u (без спецификации пути) будет, начиная с версии git версии 2.0, расчесывать индекс, чтобы найти файлы для добавления, в который входят каталоги выше ., если вы находитесь в подкаталоге с вашим репозиторием. (В Git версии 2.0, предшествующих, git add -u имеет подразумеваемое . в конце, так что он делает не смотреть на каталогах выше ..)
Вы уже отметили, что git add . добавит новые файлы, которые git add -u не будет. Тот факт, что . начинается с текущего каталога (который может и не быть верхнего уровня), является единственной реальной реальностью. (Если у вас очень большое дерево работы, вы можете увидеть некоторые различия в соотношении CPU/time/disk-activity также из-за различных стратегий поиска.)
Заметим, что то, что входит в репозиторий на следующем git commit по содержимому индекса (промежуточной области), и вы можете проверить это в любое время (например, git status или git ls-files). В большинстве случаев вам не нужно беспокоиться о раздувании репозитория. (В одном случае вы увидите временное раздувание, если git add . добавляет огромный файл, например, гигантский бинарный файл или базу данных или что-то еще, что вы затем git rm --cached и добавьте в файл .gitignore. Это потому, что это шаг git add, который фактически записывает основные BLOB-объект в репозиторий. Однако, если blob не отображается, как это будет после git rm --cached, он будет уходить на следующий сбор мусора, который происходит после gc.pruneExpire времени, который в этом случае по умолчанию составляет 14 дней.)