Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > On Thu, 19 Jul 2007, Brian Gernhardt wrote: > >> >> On Jul 19, 2007, at 8:24 AM, David Kastrup wrote: >> >> > I think that the placeholder name should rather be ".". >> >> For what it's worth, the more this gets discussed, the more I think your >> idea is a good one. > > I do not like it at all. "." already has a very special meaning. It is a > _directory_, no place holder. And this is what it will be under my scheme: a directory. It is just that "directory" is differentiated from a "tree". Both are tracked in the repository (directory tracking is optional), and there is no such thing as an empty tree, a tree being defined by its contents and nothing else, as previously. A "directory" has no contents, but only existence in index and repository. A "tree" only exists in the repository, not in index or work directory. It is mapped to physical directories in the work directory. If no corresponding "directory" exists in index and/or repository, the work directories are created and deleted on the fly as before in order to represent the state of the "tree" in the repository. So here are the concepts: entity working directory index repository -------------------------------------------------------------- file mapped to files file [blob] dir mapped to dir existence dir [dir] tree mapped to dir tree unrepresented [tree] (non-empty container) > More and more I get the impression that this thread is just not > worth it. The problem was solved long ago, and all that is talked > about here is how to complicate things. I disagree on both accounts: that the problem has been solved (the existence of a workaround involving constant manual intervention is not a solution for me), and that my proposal will constitute a complication to the user. For projects setting a "." into the top level .gitignore, nothing at all will change, even when "core.adddirs: true" will become the default at some point of time. Once this is the default, new users with new projects will not notice anything surprising, at least until the time that they pull from somebody with a repository with different non-explicit conventions. This is something which may still require thought in order to result in the least complicated handling of cooperation. But with regard to the internals itself, I don't see that there is too much non-obvious complexity involved here, and the framework appears very consistent, logical, and compatible with git's ideas to me. -- 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
