Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:

quoted text
> (
> 	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.

quoted text
> 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?

quoted text
> 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.

quoted text
> 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.

quoted text
> 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.

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html