Re: Empty directories...

Johan Herland [off-list ref] writes:

On Friday 20 July 2007, David Kastrup wrote:

quoted

Johan Herland [off-list ref] writes:

quoted

Sorry for jumping in late...

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

I have tried to keep on top of the discussion so far.

quoted

quoted

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?

No, of course I don't. But then archiving (as in tar) is intended to
recreate the "working copy" exactly as it was. Git (and other SCMs),
however, is only interested in recreating the part of the working
copy it explicitly tracks.

Yes, and
git-add some-dir
tells it to track _everything_ inside some-dir.  Which means that the
included files are tracked _implicitly_.  The included directories
(including some-dir itself) are not.

Given the following working copy:
/
/tracked/
/tracked/file
/tracked/dir/
/untracked/
/untracked/file
/untracked/dir/

and the following commands:
$ git add tracked

$ git clone

The cloned result could be any of the following:

(1)
/
/tracked/
/tracked/file

This is the current behaviour; directories are not tracked at all, but only 
added as necessary to support files.

And so your case (1) actually rather is a single line:

/tracked/file

Everything else is just part of representing /tracked/file and
disappears as soon as /tracked/file disappears.

(2)
/
/tracked/
/tracked/file
/tracked/dir/
/untracked/
/untracked/dir/

i.e. implicitly tracking _all_ directories. This is what you literally ask 
for,

I don't see how you can possibly conclude that from what I have been
writing.

but I think most would find this unreasonable.

And it is.  So please _don't_ put words into my mouth.  In my
proposal, the following (and nothing else) would get tracked:

/tracked/.
/tracked/file

and that's it.  That is what was requested, and that is what is
tracked.  There will be, incidentally, a tree "/tracked/" and a tree
"/" in the _repository_, but those collapse as soon as they are empty.
They are just an _abstract_ data structuring tool in the repository
that is _mapped_ to directories on checkout.

/
/tracked/
/tracked/file
/tracked/dir/

i.e. recursively tracking directories (and files). This seems useful, but 
there is nothing _implicit_ about this.

You did not ask for "/tracked/file" and you did not ask for
"/tracked/dir/" (whatever they may be).  That you wanted to track them
was _implied_ by your request of "/tracked/".

I have a feeling that you're actually arguing for doing (3) by
default.  What I am arguing is to do (1) by default, and (3) if
given a suitable command-line option (i.e. "git add --with-dirs
tracked").

Note that this is really an interface question.

Not at all.  It is a _conceptual_ question: in order for this to work
at _all_ (instead of being an inconsistent heap of ugly surprises),
directories need a representation in the repo.  This representation,
as opposed to in the work file system, is _optional_: the repository
got perfectly well along without it up to now, and the fallback is
already implemented when there is a tree without corresponding
directory.

How these entries are actually stored in the repo is a different
discussion.

Sure.  But anything that requires four dozens of special cases instead
of four because one wanted to keep "things that are under some
specialized view separate separate" is not something I am going to
implement.  I am too old to juggle with complexity for the sake of
complexity.  I can make much more use of the existing infrastructure
by actually making file and directory entries quite similar.

ls -la
also has no special cases for "." and ".." because they are, at a very
fundamental level, very special in achieving a special purpose
_without_ being special-cased.

Finally, let's look at the case of "git add tracked/file" followed
by "git rm tracked/file". I'm arguing that "tracked/" should be
automatically removed, since I never asked for it to be tracked by
git.

Sure.  And nobody ever said otherwise.  In fact, I gave about a dozen
examples in that line and more special in the thread up to now.

On the other hand, "git-add --non-recursive tracked" followed by the
above two commands, should of course leave "tracked/" in place,
since I now actually asked explicitly for the directory to be
tracked.

Sure.  Use "--directory" instead of "--non-recursive" and you have a
somewhat more special option for that.

My point is fundamentally that selectively tracking directories is a
more powerful concept than just tracking _all_ directories by
default.

Perhaps you might read up on some of the past discussion before
beating dead horses.  This has been covered already, and more than
once.  I never asked for "all directories" to be tracked.  I outlined
cases where they are tracked and where not, and I tested that the
mechanisms in "man gitignore" already work _perfectly_ with the
pattern "." for configuring the _implied_ tracking at directory,
repository, project, and user preference level.

Note that if we support selectively tracking directories, tracking
_everything_ (like you seem to want) is trivially implemented by
_always_ supplying the appropriate option to git-add. If we track
everything by design, we don't have the option of selectively
tracking some directories.

But that means manual intervention all of the time.  It is fine when a
tool provides an option to shoot you in the arm instead of in the foot
as usual, but that's not really a fix, but an acerbation of the
problem.

quoted

quoted

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.

I don't agree. By _selectively_ tracking directories you can
implement any policy you want on top of it.

No, you can't.  Because a "policy" means that things are _implied_.
Being able to do everything manually is not a policy.  It may be a
lifesaver at times, but then you have little business drifting in the
river in the first place.

quoted

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.

I disagree. Just as you have to decide which files to track, you
similarly should have to decide which directories to track. Of
course, the tools make this easier for you by being able to
recursively handle files. In the same way they should be able to do
the same thing for directories.

--directory _explicitly_ is not working recursively, so it does not
solve that problem.

-- 
David Kastrup