Hi, On Wed, 18 Jul 2007, David Kastrup wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > On Wed, 18 Jul 2007, David Kastrup wrote: > > > >> The FAQ answer is weazeling on several accounts: > >> > >> a) No, git only cares about files, or rather git tracks content and > >> empty directories have no content. > >> > >> In the same manner as empty regular files have no contents, and git > >> tracks those. Existence and permissions are important. > > > > We do not track permissions of directories at all. > > Ok, this seems like something that should be done as well, even if we > can stipulate at first that a directory should have rwx for the user > in question if you hope to track it. No, no, no. It should not be tracked. It is the responsibility of the _user_ to set it to something sane, be that by a umask or by sticky groups, or by setting the permissions of the parent directory. It is _nothing_ we want to put into the repository. That is the _wrong_ place to put it. > > This is because Git is primarily meant to track source code, > > Tell that to the man page. It declares git to be "a content tracker" > right at the front. Why don't you? I have no problems with the title. > > and most "permissions" (i.e. restrictions) do not make any sense > > there. > > So why are permissions for files being tracked, then? This question is invalid. Git only tracks the _executable_ bit. And again, it is the users' responsibility, by setting the umask, to have the appropriate bits set for group and others. > >> b) The problem is not just that empty directories don't get added > >> into the repository. They also don't get removed again when > >> switching to a different checkout. When git-diff returns zero, I > >> expect a subsequent checkout to not leave complete empty hierarchies > >> around because git can't delete any empty leaves which it chose not > >> to track. > > > > I _like_ the behaviour that Git does not remove a directory it > > added, when I put some untracked file into it. > > But it does not remove a directory it _refused_ to add when there were > no files at all in it ever. You probably have not read the problem > description carefully. I have. But that does not apply here, because I used the term "to add a directory" in the sense of "mkdir". > > And switching back to that branch, Git has no problems, because it > > sees that the directory is already there. In case of a file, it would > > complain, and rightfully so. > > And if you switch to a branch where the directory it did not remove now > is a file? Git already throws an error, and rightfully so. I am pleased by the current behaviour. > > See the fundamental difference between a file and a directory now? > > Condescension is not really solving a problem. Hey, I only tried to help clarify things. But since I seem to be unable to, I'll end my efforts with this suggestion: If you want to track empty directories, the best thing would be to - teach git-add to automatically create an empty .gitignore (and error out if that already exists), and - teach git-archive to not put .gitignore files into the output by default (but the directories). This might be a sensible change regardless if you want to add empty directories to the repository or not. Ciao, Dscho - 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
