On Wed, Jun 06, 2018 at 04:01:38PM -0400, Todd Zullinger wrote:
> Thomas Fischer wrote:
> > 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.
>
> It looks like this behavior has been in place for many
> years, since d9b814cc97 ("Add builtin "git rm" command",
> 2006-05-19). Interestingly, Linus noted in the commit
> message that the removal of leading directories was
> different than when git-rm was a shell script. And he
> wondered if it might be worth having an option to control
> that behavior.
>
> I imagine that most users either want the current behavior
> or they rarely run across this and are surprised, given how
> long git rm has worked this way.
It's also consistent with other parts of Git that remove files. E.g.,
"git checkout" to a state that does not have the file will remove the
leading directories (if they're empty, of course).
> It does seem like something which could be noted in the git
> rm docs. Perhaps you'd care to take a stab at a patch to
> add a note to Documentation/git-rm.txt Thomas? Maybe a note
> at the end of the DISCUSSION section?
Yeah, agreed.
-Peff
