Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Sun, 22 Jul 2007, David Kastrup wrote: >> >> "." _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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
