Re: [RFC PATCH] Re: Empty directories...

david@lang.hm writes:

On Sun, 22 Jul 2007, David Kastrup wrote:

quoted

Linus Torvalds [off-list ref] writes:

quoted

I told you. Several times. That "." is pointless exactly because
it's in _every_ tree, and as such is no longer "content".

"." is in every _non-empty_ directory tree.  But we are talking
about permitting _empty_ trees in the repository.  And for an empty
tree in the repository, "." may or may not be in the corresponding
work directory tree, depending on whether the directory exists or
not.  So when we are talking about a repository tree _becoming_
empty, we need the information whether or whether not we should
remove it upon becoming empty.  _That_ is the information content
of "." being or not being considered part of the trackable
material.  And the information is no longer available at the time
the repository tree becomes empty _unless_ we already store it
there when the tree is still populated.

David, the point where you and Linus are talking past each other is
that Linus is assuming that you only want to track some specific
directories, and for that tracking "." doesn't work becouse it's in
every directory

you apparently consider every directory equal and therefor the fact
that "." exists in every directory doesn't bother you becouse you
want to track every directory.

Sigh.  No, I don't want to track every directory.  I want to have
every directory _trackable_.  Whether it is _tracked_ depends on
whether you _add_ it to the index.  And that depends, among other
things, on the gitignore patterns, and those can be specified on a
per-directory, per-project, per-user preference.

what you are not hearing is that while Linus and the other git
developers can see reasons to track directories sometimes, they
definantly don't agree that you want to track directories all the
time.

And that is why one can use per-directory, per-project and per-user
settings to turn the tracking off, _and_ one can decide at what level
one adds information to the index.  If you always make it a habit to
only ever use git-add -f and git-rm -f on _files_ and never on
directories, you won't _ever_ see a difference on whether directories
are tracked, and the contents of .gitignore won't make a difference,
either.

But if you use git-add and git-rm on directories, then for the
specified directory and its children, .gitignore gets consulted.

sometimes the fact that a directory exists is significant, most of
the time it's not. and the difference between what is and what isn't
significant isn't a per-repository or per-project thing, it's a
per-directory thing.

Which is why one can control it per-directory using either the
.gitignore mechanism _or_ by including the directory level in question
in the git-add and git-rm commands or not.

in one repository you will have some directories that only exist
becouse files are in them, and you may have some directories that
exist becouse you explicitly want them to exist.

both types have the "." file in them (or appear to, some
OS's/filesystems don't actually have a "." on disk, they add it when
needed when reporting to userspace), so git has no way to tell which
ones you explicitly want tracked.

Like with any other file, git _has_ a way to tell.  If I don't git-add
or git-rm the directory or one of its parents to the index, I don't
want to have it tracked.  And if I add the directory or one of its
parents to the index recursively, but it is covered by .gitignore, I
don't want to have it tracked.

It is a pity that you have seemingly not read on, because there
follows a simple example:

quoted

Ok, here we go _again_.  Test case 1:

mkdir a
touch a/b
git-add a/b
git-commit -m x
git-rm a/b
git-commit -m x

Now we want to have the directory a _removed_.

Test case 2:

mkdir a
touch a/b
git-add a
git-commit -m x
git-rm a/b
git-commit -m x

Now we want to have the directory a _retained_.

After the first commit in _both_ test cases, the only file in the
trees / and /a is a/b.  The working directory state is _identical_ at
this point, and we do identical commands afterwards.

The end result is not identical, so there must be some information
different in the repository after the first commit.  This information
_can't_ be encoded in a remaining empty tree, because both the trees /
and /a are _non_-empty yet.

So we _must_ encode the evaporate-or-not-when-empty information
_otherwise_ into the repository.  And we do that by _not_ having
/a/. in the set of tracked files in test case 1, and by _having_ it in
the set of tracked files in test case 2.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

On Sun, 22 Jul 2007, David Kastrup wrote:

Sigh.  No, I don't want to track every directory.  I want to have
every directory _trackable_.

And they already are. 

Your point is pointless. You don't understand the git data structures, and 
you are trying to do something that makes no sense.

		Linus