Johan Herland <johan@xxxxxxxxxxx> writes: > 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. 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. > 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. > (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. > / > /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/". > 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. > 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. >> > 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. >> 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 - 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
