Robin Rosenberg <robin.rosenberg.lists@xxxxxxxxxx> writes: > ( > I don't know which mail is the best to reply to and I probably missed > something in the thread, so bear with me if I'm repeating anything. > ) > > David. Reconsider "tracking" all directories and what that would > give, compared to explicitly tracking specific ones and the requires > magic entries. It would be quite a nuisance for a patch-based workflow, since patches don't talk about the creation and deletion of directories. The "track only when entered approach" has the advantage that directories that were only created to accommodate patches will be removed again when becoming empty. Of course, once doing "git-add top-level" will level the difference. > Say we have a config setting that tells git never to remove empty > trees. Why wouldn't I have tree/zap removed when doing git-rm tree? > Linus patches could be a start for representing trees in the > index. As an optimization the index could prune trees from the index > if they contain things as long as the index *effectively* remembers > all trees. But it doesn't. If you do git-add tree, optimizing the dir entry away since tree/zap exists, then subsequently do git-rm tree/zap, of course there is nothing to do except remove tree/zap, and the tree is gone. One can't start tracking trees explicitly only when they become empty, because one can't know whether to track them then. > Using the patches again we could add empty directories to the index > and remove them. No directory would be removed automatically, except > maybe by a merge. I currently have the problem that rm -rf * unzip some-archive git-add some-archive git-commit -a -m whatever git-checkout something else leaves empty directory skeletons lying around. > We would probably have only a few empty directories and new > unexpected ones would only pop up when we remove all blobs from > one. Git status could tell us about them so we will not forget > them. I don't want a source management system to tell me whenever it is going to annoy me. > It could even tell us about "new" empty directories, which is > probably the most important thing you'd want to know. > > Forgetting to untrack an empty directory would not be a big deal. > > Whether to retain empty trees or not should be a repository policy, > but an all or nothing setting. With that approach idea the workflow "Apply a patch creating something/hello" "Undo the patch creating something/hello" will leave something lying around. For somebody managing hundreds of directories, that would be a nuisance. I don't say that a "track all parents automatically" approach would not have its merits: it would likely prevent some mistakes and be easily understandable to most users. But for managing a patch workflow, it would appear to get in the way. -- 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
