Re: git rm bug

From: Jeff King <peff@peff.net>
Date: Jun 6, 2018, 20:11 UTC
Message-ID: <20180606201144.GA32098@sigill.intra.peff.net>
In-Reply-To: <20180606200137.GJ3094@zaya.teonanacatl.net>

On Wed, Jun 06, 2018 at 04:01:38PM -0400, Todd Zullinger wrote:

Show 20 quoted lines

> 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