I agree that the entire chain of empty directories should not be tracked, as git tracks content, not files.
However, when I run 'rm path/to/some/file', I expect path/to/some/ to still exist. Similarly, when I run 'git rm path/to/some/file', I expect path/to/some/ to exist, *albeit untracked*. I do NOT expect git to *track* empty directories. But I also do NOT expect it to remove untracked directories. -- Thomas Fischer thomasfisc...@fastmail.com On Wed, Jun 6, 2018, at 2:33 PM, Robert P. J. Day wrote: > On Wed, 6 Jun 2018, Thomas Fischer wrote: > > > OVERVIEW > > > > "git rm" will remove more files than specified. This is either a bug or > > undocumented behavior (not in the man pages). > > > > SETUP > > > > 1. In a git repository, create an empty directory OR a chain of empty > > directories > > > > $ mkdir -p path/to/some/ > > > > 2. Create a file in the deepest directory and add it to tracking > > > > $ touch path/to/some/file > > $ git add path/to/some/file > > $ git commit -m 'add path/to/some/file' > > > > THE BUG > > > > Run 'git rm' on the tracked file. > > > > EXPECTED BEHAVIOR > > > > $ git rm path/to/some/file > > rm 'path/to/some/file' > > $ ls path > > to/ > > $ ls path/to > > some/ > > > > Note that path/, path/to/, and path/to/some/ still exist. > > > > ACTUAL BEHAVIOR > > > > $ git rm path/to/some/file > > rm 'path/to/some/file' > > $ ls path > > ls: cannot access 'path': No such file or directory > > > > The entire chain of empty directories is removed, despite the fact > > the git outputs only "rm 'path/to/some/file'". > > git cannot track empty directories. as that was the *only* content > in that whole hierarchy, the entire hierarchy had to be deleted. > > rday
