Re: [RFC PATCH] Re: Empty directories...

[David Kastrup <dak@gnu.org>]

Tomash Brechko <tomash.brechko@gmail.com> writes:

> Hi David,
>
> On Thu, Jul 19, 2007 at 13:31:50 +0200, David Kastrup wrote:
>> core.excludefile: .
>
> Really nice idea to give directories 'DIR/.' name.  I'm sure there are
> several other ways to implement your proposal.  But why to put in in
> Git itself?  Decomposition and abstraction principle tells me that
> this should go to some other place.

Because of a fundamental law of computation: information maintained in
two separate places will get out of synch eventually.

> Please consider this: I myself use Git to track my own local
> projects, and for this usage you proposal have no value for me,
> i.e. as a _Source_ Code Management system Git is rather complete.
> But I also track /etc and ~/ in Git, and for this I'd love to have
> directories, permissions, ownership, other attributes, to be
> tracked.  I have Perl script wrapping Git that allows me to filter
> tracked paths by full regexps instead of Git's file globs, and also
> to filter out too big files assuming that they are binary anyway.

Look, git _tracks_ contents.  Your permissions managements needs to be
told explicitly when and how things change.  So you end up with git
_tracking_ material and your permissions/directory management needing
the level of manual handholding Subversion demands.

> And my point is that rather than building the support for all of it
> into core Git, and then implementing sophisticated configuration to
> disable parts of it, wouldn't it be better to have a separate tools
> orthogonal to Git itself?

And my personal answer to that is "no".  We don't want orthogonality
for intimately related things, because it forces us to work the
"orthogonal" things in lockstep.  And if you force git to operate in
lockstep with manual explicit tracking, then git becomes useless for
tracking stuff automatically.

> So the essence of my objection is that we should not pollute core
> Git with file system state tracking more than it's required to know
> where to put the contents to.  Everything else should go elsewhere.
>
> Again, I'd love to have your proposal be implemented, but only in a
> way that won't interfere with pure SCM's operations.

Tell git to ignore "." and it won't "interfere".

-- 
David Kastrup