Junio C Hamano <gitster@xxxxxxxxx> writes: > Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > >> So the whole notion of "remembering" whether a directory was added >> explicitly as an empty directory or not is just not a sensible concept in >> git. > > That is true if it is implemented as David suggested, to have a > phony "." entry in the tree object itself. The object name of such > a tree (when it contains blobs and trees underneath) will be > different from a tree that contains the same set of blobs and trees. > It would destroy the fundamental concepts of git. How so? > But you _could_ treat that "should-be-kept-even-when-empty"-ness > just like we treat executable bit on blobs, I think. > > When blobs with the same contents but of different type (REG vs LNK) > and regular file with or without executable bit are entered in git, > they all get the same SHA-1 but we can still tell them apart because > the index and the tree entry have mode bits. So hypothetically, you > could introduce "sticky" directory in tree entries to mark "this > will not go away when emptied". A tree containing files with and without executable bits will show different SHA-1 sums. There is no reason that this should be different for a tree containing the conceptual "." or not. I won't fight for a specific implementation but if I am going to implement this (and the current lack of enthusiasm points to that) I will not go and duplicate the entire ignore/add/rm/index/repository machinery in order to have a bit rather than an actual "." directory entry. Most Unix file systems have an honest, physical, down-to-Earth directory entry "." even on disk because it _simplifies_ matters, even though one could special-case "." all throughout and make do without a physical entry in theory. And, as I explained, "." lends itself perfectly to the gitignore machinery in order to policy projects to track or not track directories. > In a 'tree' object, they might appear as: > > 40000 ordinary-directory '\0' 20-byte SHA-1 > 41000 directory-dontremove-even-if-empty '\0' 20-byte SHA-1 > > In 'index', as your "I'm soft" patch, we do not have to add > nonsticky kind of tree nodes, It does not work, since then you can't distinguish mkdir A touch B git-add A/B from mkdir A touch B git-add A It is very clear that git-rm A/B _mustn't_ leave an empty directory in the first case, and _must_ leave an empty directory in the second case _if_ and only if one tracks directories. > Obviously, this "sticky" bit will cascade up and make your otherwise > equivalent parent tree's different, No, it must not "cascade up". After mkdir -p A/B touch A/B/C git-add A/B git-rm A/B there must be nothing tracked by git. The "sticky" bit does not "cascade up". Its upward effect is only changing the SHA-1 of the tree, like any change below does. > This will involve a lot of changes, so I would not recommend anybody > doing so, though. Neither would I. Why people want to complicate the code base everywhere by avoiding to treat "." like a legitimate entry (as Unix file systems do for a _reason_) is simply a miracle to me. The framework is pretty much _there_. There is no point in not making use of it and duplicating the whole machinery because we want a "bit set" implementation instead of a file name. -- 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
