Well, coming back to this posting in order to focus on some points that were at a level more relevant to the implementation. And I'll go through the questions assuming my permissions-based proposal. Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Thu, 19 Jul 2007, David Kastrup wrote: >> >> Well, kudos. Together with the analysis from Junio, this seems like a >> good start. Would you have any recommendations about what stuff one >> should really read in order to get up to scratch about git internals? > > Well, you do need to understand the index. That's where all the new > subtlety happens. > > The data structures themselves are trivial, and we've supported > empty trees (at the top level) from the beginning, so that part is > not anything new. > > However, now having a new entry type in the index (S_IFDIR) means > that anything that interacts with the index needs to think > twice. But a lot of that is just testing what happens, and so the > first thing to do is to have a test-suite. Yes. > There's also the question about how to show an empty tree in a > diff. Well, there are two possibilities involved here, a more and a less chatty one. Assuming that we want to do as little work as possible, the transition between a tracked and a non-tracked directory will be given in one of the following manners: Either: a) xxx: old mode 000000 xxx: new mode 040755 when a directory gets tracked and xxx: new mode 040755 xxx: old mode 000000 when it gets untracked again. or b) xxx: new directory mode 040755 when a directory gets tracked and xxx: deleted directory mode 040755 when it gets untracked again. Note that "new" does not mean that git did not previously have had files that absolutely have required a directory for placing. It just means that it has now actively gained knowledge about the directory. In a similar vein, "deleted" means that git is just deleting its knowledge about the directory, _scheduling_ it for a single deletion attempt at the earliest (and actually also latest) opportunity: when git happens to know about no more files that require keeping the directory around. So perhaps the following would be more readable: xxx: tracking directory mode 040755 xxx: forgetting directory mode 040755 Now in order to cut down on the verbiage, it might be an option to transmit those strings only when something happens that can't be deduced from other data. Because _if_ it can be deduced from other data (like a directory being present when files in it are), then at least the working copies are identical as long as both persons don't start deleting files from the repository. If they do so, when a directory becomes empty, the other side needs to know whether the directory is being tracked or not if it still wants to maintain the same state in the working tree. But if we really want to have not just the working tree but also the repositories in SHA1-lockstep, we can't delay transmitting this information. > We've never had that: the only time we had empty trees was when we > compared a totally empty "root" tree against another tree, and then > it was obvious. But what if the empty tree is a subdirectory of > another tree - how do you express that in a diff? Do you care? Right > now, since we always recurse into the tree (and then not find > anything), empty trees will simply not show up _at_all_ in any > diffs. One would still recurse. > And what about usability issues elsewhere? With my patch, doing something > like a > > git add directory/ > > still won't do anything, because the behaviour of "git add" has always > been to recurse into directories. This will remain the same, but the directory itself will be added if and only if the corresponding preference variable is set, regardless of whether the directory is empty. > So to add a new empty directory, you'd have to do > > git update-index --add directory > > and that's not exactly user-friendly. Presumably one could, if one really wanted an explicit way, have git add --directory directory in analogy to the --directory option of the ls command. But I think that in most cases one would not want to treat one directory different from the whole tree, so the implicit behavior regulated by a project-wide preference should be sufficient in general. > So do you add a "-n" flag to "git add" to tell it to not recurse? Or > do you always recurse, but then if you notice that the end result is > empty, you add it as a directory? I always recurse (unless there is a --directory option and I have some strange desire to actually use it). I add it as a directory, regardless of whether it is empty or not, if my preference setting (or gitignore or whatever) is set to tracking directories. -- 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
