Re: Empty directories...

Johan Herland [off-list ref] writes:

On Wednesday 18 July 2007, Junio C Hamano wrote:

quoted

Didn't I say I do not have an objection for somebody who wants
to track empty directories, already?  I probably would not do
that myself but I do not see a reason to forbid it, either.

The right approach to take probably would be to allow entries of
mode 040000 in the index.  Traditionally, we allowed only 100644
(blobs as regular files) and 120000 (blobs as symlinks).  We
recently added 160000 (commit from outer space, aka subproject).

And we do that for all directories, not just empty ones.  So if
you have fileA, empty/, sub/fileB tracked, your index would
probably have these four entries, immediately after read-tree
of an existing tree object:

Sorry for jumping in late...

It could have given you a chance to read up on what has already been
discussed.

Why do you want to add _all_ directories, and not just the ones we
want to explicitly track (independent of whether they're empty or
not).

Because the problematic cases are more often than not the _implicit_
cases.  Do you check a directory tree for empty directories before you
archive it?  In order to archive every empty directory explicitly?

If you did that, you could equally maintain a script that manually
does mkdir/rmdir.

Basically, add a "--dir" flag to git-add, git-rm and friends, to
tell them you're acting on the directory itself (rather than its
(recursive) contents). "git-add --dir foo" will add the "040000
123abc... 0 foo" to the index/tree whether or not foo is an empty
directory. "git-rm --dir foo" will remove that entry (or fail if it
doesn't exist), but _not_ the contents of foo.

There is nothing wrong with implementing something like this in
_addition_ to treating directory entries implicitly.  For example, ls
has an option -d which does just that, and even git-ls-files has an
option --directory.  Heck, I even have

rm --help
Usage: rm [OPTION]... FILE...
Remove (unlink) the FILE(s).

  -d, --directory       unlink FILE, even if it is a non-empty directory
                          (super-user only; this works only if your system
                           supports `unlink' for nonempty directories)
[...]

which works on just the directory and not on the contents.

So a --directory option for appropriate commands would be natural for
_explicit_ manipulation of such entries.

But the important, the _really_ important thing are the implicit
behaviors.  If I have to hassle with every directory myself, I don't
need a content tracking system.

The --directory stuff, in contrast, are things nice to have when the
framework is in place (and may be even necessary for some direct
manual maintenance tasks), but they don't really concern the
framework.

-- 
David Kastrup