Linus Torvalds [off-list ref] writes:
On Sun, 22 Jul 2007, David Kastrup wrote:
quoted
"." _is_ visible and detectable in every tree.
I'm going to add you to my "clueless" filter, because it's not worth
my time to answr you any more.
Too bad I can't do the same.
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.
It's not something that the user can care about, because it has no
meaning. There's no point in tracking it, because even if we do
*not* track it, it's there, and we cannot do anything about it.
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.
That was the whole difference between "." and ".gitignore", and I
explicitly pointed out that that was the difference (and the _only_
one), and why it mattered.
You are underestimating the power of ".gitignore": while it is true
that its _physical_ presence will reliably keep git from removing the
directory, its physical presence is not _actually_ required.
It is sufficient that git _believes_ in its continuing physical
existence. And if we tell it "it is still there" whenever it takes a
look, then git will keep the record of .gitignore in its tree, and
consequently won't remove the tree and not try deleting the directory.
However, once we explicitly tell it "remove the record of .gitignore
from the repository", it will do so, and in the course of doing so
remove the directory in the work directory together with the tree in
the repository.
From a user interface and logical standpoint, adding or not adding "."
to the tracked content is a perfectly consistent and convenient way of
having the directory kept around or not.
From the viewpoint of the internal data structures, I'll likely go
with tampering with (pseudo-)permissions.
And you didn't listen. And now you claim that I don't read your
emails. I do. They just don't make any sense.
Consider this discussion ended. I simply don't care any more.
It is painfully clear that I could invest a few weeks of time in
coding better than in explaining stuff. And I guess that's what I'll
have to do. And afterwards it will be your job to wrack your head
about why something does all the right things for the wrong reasons
and come up with a different explanation how and why the code works.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
On Sun, 22 Jul 2007, David Kastrup wrote:
Linus Torvalds [off-list ref] writes:
quoted
On Sun, 22 Jul 2007, David Kastrup wrote:
quoted
"." _is_ visible and detectable in every tree.
I'm going to add you to my "clueless" filter, because it's not worth
my time to answr you any more.
Too bad I can't do the same.
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.
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.
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.
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.
creating .gitignore in the directories that you want tracked lets the
other directories not be trackes.
David Lang
quoted
It's not something that the user can care about, because it has no
meaning. There's no point in tracking it, because even if we do
*not* track it, it's there, and we cannot do anything about it.
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.
quoted
That was the whole difference between "." and ".gitignore", and I
explicitly pointed out that that was the difference (and the _only_
one), and why it mattered.
You are underestimating the power of ".gitignore": while it is true
that its _physical_ presence will reliably keep git from removing the
directory, its physical presence is not _actually_ required.
It is sufficient that git _believes_ in its continuing physical
existence. And if we tell it "it is still there" whenever it takes a
look, then git will keep the record of .gitignore in its tree, and
consequently won't remove the tree and not try deleting the directory.
However, once we explicitly tell it "remove the record of .gitignore
from the repository", it will do so, and in the course of doing so
remove the directory in the work directory together with the tree in
the repository.
From a user interface and logical standpoint, adding or not adding "."
to the tracked content is a perfectly consistent and convenient way of
having the directory kept around or not.
From the viewpoint of the internal data structures, I'll likely go
with tampering with (pseudo-)permissions.
quoted
And you didn't listen. And now you claim that I don't read your
emails. I do. They just don't make any sense.
Consider this discussion ended. I simply don't care any more.
It is painfully clear that I could invest a few weeks of time in
coding better than in explaining stuff. And I guess that's what I'll
have to do. And afterwards it will be your job to wrack your head
about why something does all the right things for the wrong reasons
and come up with a different explanation how and why the code works.
On Sun, 22 Jul 2007, David Kastrup wrote:
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.
You're pointless.
We have no problems at all with non-empty trees. We know exactly what they
are. We keep track of them fine, and we do not need a totally pointless
"." entry for them.
But we are talking about
permitting _empty_ trees in the repository.
And WE ALREADY DO.
The empty tree looks like this: "". It has a SHA1 of
4b825dc642cb6eb9a060e54bf8d69288fbee4904. It works today, and in fact, git
uses it already.
Try this:
git ls-tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
in the git repository. What do you think that is?
Your "." is *pointless*.
And it's _worse_ than pointless: it's not "content". It doesn't add any
information. It's not something you can match up against the working tree
meaningfully, exactly because *every* working tree has it. As such, it's
total non-information.
Linus
On Sun, 22 Jul 2007, David Kastrup wrote:
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.
You don't seem to realize - although I've told you now abotu a million
times - that what you are talking about is:
- technically exactly the same as ".gitignore", which for some
unfathomable reason you cannot seem to accept.
- except your use of "." is 100% INFERIOR exactly because the "." entry
has no meaning in the target filesystem, so it means that the bit of
information is no longer something that is trackable in the working
tree.
Quite frankly, Junio would be a total idiot to take any patches that do
what you want to do. Happily, he is anything but.
Linus