Re: Empty directories...

From: David Kastrup <dak@gnu.org>
Date: Jul 20, 2007, 10:54 UTC
Message-ID: <86tzrzuyyy.fsf@lola.quinscape.zz>
In-Reply-To: <200707201220.15114.johan@herland.net>

Johan Herland <johan@herland.net> writes:

Show 22 quoted lines

> On Friday 20 July 2007, David Kastrup wrote:
>> Johan Herland <johan@herland.net> writes:
>> > Sorry for jumping in late...
>> 
>> It could have given you a chance to read up on what has already been
>> discussed.
>
> I have tried to keep on top of the discussion so far.
>
>> > Why do you want to add _all_ directories, and not just the ones we
>> > want to explicitly track (independent of whether they're empty or
>> > not).
>> 
>> Because the problematic cases are more often than not the
>> _implicit_ cases.  Do you check a directory tree for empty
>> directories before you archive it?  In order to archive every empty
>> directory explicitly?
>
> No, of course I don't. But then archiving (as in tar) is intended to
> recreate the "working copy" exactly as it was. Git (and other SCMs),
> however, is only interested in recreating the part of the working
> copy it explicitly tracks.

Yes, and git-add some-dir tells it to track _everything_ inside some-dir. Which means that the included files are tracked _implicitly_. The included directories (including some-dir itself) are not.

Show 23 quoted lines

> Given the following working copy:
> /
> /tracked/
> /tracked/file
> /tracked/dir/
> /untracked/
> /untracked/file
> /untracked/dir/
>
> and the following commands:
> $ git add tracked
>
> $ git clone
>
> The cloned result could be any of the following:
>
> (1)
> /
> /tracked/
> /tracked/file
>
> This is the current behaviour; directories are not tracked at all, but only 
> added as necessary to support files.

And so your case (1) actually rather is a single line:

/tracked/file

Everything else is just part of representing /tracked/file and disappears as soon as /tracked/file disappears.

Show 10 quoted lines

> (2)
> /
> /tracked/
> /tracked/file
> /tracked/dir/
> /untracked/
> /untracked/dir/
>
> i.e. implicitly tracking _all_ directories. This is what you literally ask 
> for,

I don't see how you can possibly conclude that from what I have been writing.

> but I think most would find this unreasonable.

And it is. So please _don't_ put words into my mouth. In my proposal, the following (and nothing else) would get tracked:

/tracked/. /tracked/file

and that's it. That is what was requested, and that is what is tracked. There will be, incidentally, a tree "/tracked/" and a tree "/" in the _repository_, but those collapse as soon as they are empty. They are just an _abstract_ data structuring tool in the repository that is _mapped_ to directories on checkout.

Show 7 quoted lines

> /
> /tracked/
> /tracked/file
> /tracked/dir/
>
> i.e. recursively tracking directories (and files). This seems useful, but 
> there is nothing _implicit_ about this.

You did not ask for "/tracked/file" and you did not ask for "/tracked/dir/" (whatever they may be). That you wanted to track them was _implied_ by your request of "/tracked/".

Show 6 quoted lines

> I have a feeling that you're actually arguing for doing (3) by
> default.  What I am arguing is to do (1) by default, and (3) if
> given a suitable command-line option (i.e. "git add --with-dirs
> tracked").
>
> Note that this is really an interface question.

Not at all. It is a _conceptual_ question: in order for this to work at _all_ (instead of being an inconsistent heap of ugly surprises), directories need a representation in the repo. This representation, as opposed to in the work file system, is _optional_: the repository got perfectly well along without it up to now, and the fallback is already implemented when there is a tree without corresponding directory.

> How these entries are actually stored in the repo is a different
> discussion.

Sure. But anything that requires four dozens of special cases instead of four because one wanted to keep "things that are under some specialized view separate separate" is not something I am going to implement. I am too old to juggle with complexity for the sake of complexity. I can make much more use of the existing infrastructure by actually making file and directory entries quite similar.

ls -la also has no special cases for "." and ".." because they are, at a very fundamental level, very special in achieving a special purpose _without_ being special-cased.

> Finally, let's look at the case of "git add tracked/file" followed
> by "git rm tracked/file". I'm arguing that "tracked/" should be
> automatically removed, since I never asked for it to be tracked by
> git.

Sure. And nobody ever said otherwise. In fact, I gave about a dozen examples in that line and more special in the thread up to now.

> On the other hand, "git-add --non-recursive tracked" followed by the
> above two commands, should of course leave "tracked/" in place,
> since I now actually asked explicitly for the directory to be
> tracked.

Sure. Use "--directory" instead of "--non-recursive" and you have a somewhat more special option for that.

> My point is fundamentally that selectively tracking directories is a
> more powerful concept than just tracking _all_ directories by
> default.

Perhaps you might read up on some of the past discussion before beating dead horses. This has been covered already, and more than once. I never asked for "all directories" to be tracked. I outlined cases where they are tracked and where not, and I tested that the mechanisms in "man gitignore" already work _perfectly_ with the pattern "." for configuring the _implied_ tracking at directory, repository, project, and user preference level.

Show 5 quoted lines

> Note that if we support selectively tracking directories, tracking
> _everything_ (like you seem to want) is trivially implemented by
> _always_ supplying the appropriate option to git-add. If we track
> everything by design, we don't have the option of selectively
> tracking some directories.

But that means manual intervention all of the time. It is fine when a tool provides an option to shoot you in the arm instead of in the foot as usual, but that's not really a fix, but an acerbation of the problem.

Show 12 quoted lines

>> > Basically, add a "--dir" flag to git-add, git-rm and friends, to
>> > tell them you're acting on the directory itself (rather than its
>> > (recursive) contents). "git-add --dir foo" will add the "040000
>> > 123abc... 0 foo" to the index/tree whether or not foo is an empty
>> > directory. "git-rm --dir foo" will remove that entry (or fail if
>> > it doesn't exist), but _not_ the contents of foo.
>> 
>> There is nothing wrong with implementing something like this in
>> _addition_ to treating directory entries implicitly.
>
> I don't agree. By _selectively_ tracking directories you can
> implement any policy you want on top of it.

No, you can't. Because a "policy" means that things are _implied_. Being able to do everything manually is not a policy. It may be a lifesaver at times, but then you have little business drifting in the river in the first place.

Show 9 quoted lines

>> But the important, the _really_ important thing are the implicit
>> behaviors.  If I have to hassle with every directory myself, I
>> don't need a content tracking system.
>
> I disagree. Just as you have to decide which files to track, you
>similarly should have to decide which directories to track. Of
>course, the tools make this easier for you by being able to
>recursively handle files. In the same way they should be able to do
>the same thing for directories.

--directory _explicitly_ is not working recursively, so it does not solve that problem.

-- 
David Kastrup