Linus Torvalds <torvalds@linux-foundation.org> writes:

quoted text
> On Wed, 18 Jul 2007, David Kastrup wrote:
>
>> b) The problem is not just that empty directories don't get added
>> into the repository.  They also don't get removed again when
>> switching to a different checkout.
>
> Bzzt. Wrong.
>
> We *do* remove directories when all files under them go away.

But empty directories which were empty to start with don't go away
since they are not tracked.  And that means that their parents don't
go away.

Git will remove directories which _had_ git-tracked content prior to
the checkout.  But it will not register empty directories created
outside of git, and consequently will not remove them.

quoted text
> HOWEVER (and this is where one of the reasons for not tracking them
> comes in):
>
>    ** YOU CANNOT REMOVE A DIRECTORY IF IT HAS SOME UNTRACKED CONTENTS **
>
> Think about that for five seconds, then think about it some
> more. Ponder it.

Linus, condescension is all very nice, but I already told you: I had a
directory hierarchy created outside of git's control (every file comes
into being first outside of git).  This hierarchy contained empty
directories.  The while hierarchy was committed into git.  git
silently skipped registering empty directories.  Then a different
version got checked out which did not contain the directory hierarchy
in question.  And git left the (unregistered) empty directories in, as
well as all their parent directories.

And that is just plain wrong.

quoted text
> So the fact is, git *already* does ass good of a job as it could
> possibly do wrt directories that go away: it tries to remove them if
> all the files that are tracked in it have gone away.

But I told git to track the whole directory tree recursively.  There
were no uncommitted files it complained about.  It is not reasonable
that it is afterwards unable to remove this when I checkout some other
tag.

quoted text
> A SCM *must*not* just remove that directory. It would be
> horrible. The fact that it has untracked files in it does not make
> those untracked files "unimportant".

Sure.  But that it refuses to track the files makes the total behavior
an annoyance.  I don't complain _how_ git handles not being able to
track empty directories.  I complain about it not being able to track
them in the first place.  The consequences are hideous.

quoted text
> Maybe you feel that way about object files, but what about tracking
> some important parts of your home directory - does the fact that you
> don't necessarily track *all* of it mean that the rest is totally
> unimportant adn that git should just remove it? HELL NO!

When I tell it to track it, it should not refuse.  Even if it is
empty.  Because if it _stayed_ empty, git can then remove it (and
possibly the parents) when I checkout something else.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html