David Kastrup <dak@xxxxxxx> writes: > Jakub Narebski <jnareb@xxxxxxxxx> writes: > >> I think it would be best implemented by repository config, e.g. I got sidetracked here: the gitignore stuff has in the dirmod scheme actually no code or concept overlap with the actual scheme, so it can be considered a distraction for now and its implementation and discussion tabled. It has one disadvantage: in order to get _recursive_ behavior in one tree, one needs to use the "." pattern in the .gitignore file of the respective directory, and having a .gitignore file in that directory sort of defeats the idea of not having .gitignore directories around... Of course, a single .gitignore file is better than ones one has to distribute through the tree. >> core.dirManagement or something like that, which could be set to >> 1. "autoremove" or something like that, which gives old behavior >> of untracking directory if it doesn't have any tracked files >> in it, and removing directory if it doesn't have any files >> in it. > > That's actually not _tracking_ a directory at all, but rather > maintaining an independent directory in the parallel repository > universe. No information specific to directories passes the index. Note: that was merely a comment on semantics, not on the matter. >> 2. "noremove" or something like that, which changes the behaviour >> to _never_ untrack directory automatically. This can be done >> without any changes to 'tree' object nor index. It could be useful >> for git-svn repositories. > > I don't see how this could occur. Automatic _untracking_ would happen > when one untracks (aka removes) a parent directory. But one would not > do this while keeping the child. Correction: if there was a --directory option and one used it for git-rm (or no -r was given, so just one directory level was effected), one _could_ untrack stuff on the git side accidentally. And for something like git-svn, this might be a bad idea. So there is conceivably a market for an option that never untracks a non-empty tree. >> 3. "marked" or something like that, for which you have to explicitely >> mark directories which are not to be removed when empty. > > Equivalent to 1 in my scheme. At least if scheme 1 does not forbid some _explicit_ way of saying "track this and I really mean it". >> 4. "recursive" or something like that, which would automatically mark >> as "sticky" all subdirectories added in a "sticky" repository. > > If they are covered by the add and not just implied by childs. That is, > git-add a/b > will not make "a" sticky while > git-add a > will make a/b sticky. Addition: I was thinking so much of my implementation and its semantics that I did not consider one possibility that you might mean here: When adding a/b, always also add a (and the whole hierarchy above it) automatically as sticky. Namely disallow unsticky directories in the repository at all. That would mean that git-add a/b;git-commit -m x;git-rm a/b;git-commit -m x might not be a noop if a was not in the repository previously: it would cause a to stay around sticky until removed. With all other schemes, however, it would cause a to be removed "on behalf of the user" even if the user intended it to stay around. Indeed, this scheme might by far be the easiest to understand. Having no autoremoval at all in levels higher than the deleted level is something that people might easily understand: delayed removal just does not happen anymore, and git never deletes a directory unless told to. -- 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
