David Kastrup <dak@xxxxxxx> writes: > 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. And of course, it would be a nuisance for people managing a patch-based workflow. But those can actually easily set the repository preferences differently, and even find -type d -empty -delete is not too hard to do. So it would even be feasible as default. But I think that in practice, the "track only what has been added recursively" approach is a good default. And since patches without dir information never add anything recursively, it would mostly keep the directories clean. -- David Kastrup - 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
