On Friday 20 July 2007, David Kastrup wrote: > Johan Herland <johan@xxxxxxxxxxx> 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. 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. (2) / /tracked/ /tracked/file /tracked/dir/ /untracked/ /untracked/dir/ i.e. implicitly tracking _all_ directories. This is what you literally ask for, but I think most would find this unreasonable. (3) / /tracked/ /tracked/file /tracked/dir/ i.e. recursively tracking directories (and files). This seems useful, but there is nothing _implicit_ about this. 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. How these entries are actually stored in the repo is a different discussion. 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. 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. My point is fundamentally that selectively tracking directories is a more powerful concept than just tracking _all_ directories by default. 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. > > 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. > For example, ls > has an option -d which does just that, and even git-ls-files has an > option --directory. Heck, I even have Yes, having commandline options for explicitly specifying directories (and not their contents) is _exactly_ what I want. > 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. Have fun! ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net - 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
