Jakub Narebski <jnareb@xxxxxxxxx> writes: > David Kastrup wrote: > >> So I pretty much can rule out that I am wrong on the factual side. > > Big words. Sure. It is not relevant, however. > First, there is little matter of something like area of competence. > You might be systems master, but your idea about snapshot based > distributed revision control systems can be wrong because DSCM are > outside the area you know most about. Slicing the concept of directory and tree into two separate things and thinking separately about them and their relation in working tree and repository is not exactly concerned with the internals. It obviously was too artificial a concept to be understandable, and likely a worse idea than necessary (whether one wants to call it too smart or too stupid for its own good may be a matter of taste). Anyway, it would be more productive if we managed to focus on the technical aspects again. I accept that my previous proposal was not fit for inclusion. > Second, even if you are a master at given topic, you can still be > wrong. > > Mind you, I was not saying you are wrong. I was saying you could be. We can leave that open since no code is going to come of the first proposal. > [...] >> The recursiveness of the gitignore mechanism has the advantage that >> when maintaining a large repository with actual or logical >> subprojects, one does not need to pick a single policy for all >> subprojects. > > I think it would be best implemented by repository config, e.g. > core.dirManagement or something like that, which could be set to > 1. "autoremove" or something like that, which gives old behavior > of untracking directory if it doesn't have any tracked files > in it, and removing directory if it doesn't have any files > in it. That's actually not _tracking_ a directory at all, but rather maintaining an independent directory in the parallel repository universe. No information specific to directories passes the index. > 2. "noremove" or something like that, which changes the behaviour > to _never_ untrack directory automatically. This can be done > without any changes to 'tree' object nor index. It could be useful > for git-svn repositories. I don't see how this could occur. Automatic _untracking_ would happen when one untracks (aka removes) a parent directory. But one would not do this while keeping the child. > 3. "marked" or something like that, for which you have to explicitely > mark directories which are not to be removed when empty. Equivalent to 1 in my scheme. > 4. "recursive" or something like that, which would automatically mark > as "sticky" all subdirectories added in a "sticky" repository. If they are covered by the add and not just implied by childs. That is, git-add a/b will not make "a" sticky while git-add a will make a/b sticky. > OR directory is not removed when empty if it is marked as such, > or one of its parents is marked as such. I'd not throw too much inheritance into the equation, or things become intractable too easily. > The "magic mode" solution _should_ work also with older git, I > think. I think so, too, for the repository. But of course what happens in the index with old code when new data types get added is a case for review, testing and praying. >>> Fourth, is very artificial. What would you put for filemode for '.'? >>> 040000 (i.e. directory)? > [...] >>> What would you put for sha1? Sha1 of an empty directory? >> >> Some fixed value. Everywhere the same. Not really relevant. > > Relevant because it has to work with legacy git on strange operating > systems. Because git has to fsck it (and adding special casing this > "some fixed value" to git-fsck is bad, bad idea). I did not mean "arbitrary value", but the value would be computed in a standard way from the node, and since the node would be the same everywhere, the hash would be too. > Note that sha1 cannot be sha1 of the tree. In working area '.' is > self link. You cannot create self link in git repository object. Certainly. And the idea was to have "." be isolated from the contents of the tree, basically treating it as a sibling of the other entries. Which is, in a way, how "." shared one namespace in Unix with what amounts to _children_ of the corresponding tree. So that was some inspiration here, probably too much so. > [...] >>>> And the repository is a versioned and hierarchically hashed version >>>> of the index, but its trees contain _no_ information that is not >>>> already inherently represented by the files alone. [...] > [...] >>> Trees do contain information which is not inherently present by the >>> blobs. >> >> Could you give examples for such information? As long as we are not >> talking about _history_, I am at a loss at what else you mean. File >> names and permissions? > > File names and permissions. And they bind blobs and trees together. Trees bind blobs and trees together? Anyway, I consider the names and permissions properties of the files and their identity. Stripping out the blobs from under them does not actually add any information: the trees still don't contain any information that would have necessitated looking at directories rather than just files, their names, permissions and content in the work space. But you are right in that the tree can't be replaced by the blobs. It actually needs the files (namely their full names and permissions) to reconstruct it. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum - 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
