David Kastrup <dak@gnu.org> writes:

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