On Friday 20 July 2007, Linus Torvalds wrote: > [...] > > But that doesn't change the fundamental issue: the limitation with > executable bits and symlinks is a limitation of the broken environment, > not of git. But "directories stay around after the last file is gone" is > not that, it would simply be a design mistake in git itself. > > There are other reasons to not do it. What about file renames? Maybe the > directory got *renamed*. From a pure content angle, this is "all the files > in that directory went away". If you have stupid rules like "directories > stay around even though all the files went away", you would again have > problems with this common case. > > In other words: I don't care one whit about the whiners. What's MUCH more > important than some random whiny person saying "Daddy, daddy, I want a > pony" is whether you can afford to maintain that pony in the future. And > this pony is just stupid. > > So here: > > No, you cannot have a pony. NOT YOURS. > > but I still think we should support the concept of importing things from > other systems, and thus eventually support empty directories. Just not any > crazy semantics with sticky histories. Does this mean that you are firmly opposed to the concept of storing directories in the index/tree as such, or that you are only opposed to (some of) the implementation ideas that have been discussed so far? If the former is the case, does this mean that there will be no support for empty directories in git, alternatively that such support is limited to incorporating e.g. Dscho's .gitignore workaround into porcelain commands (i.e. "git add --directory some_dir" will be mangled/transformed into "touch some_dir/.gitignore && git add some_dir/.gitignore")? (Granted, Dscho's .gitignore workaround is fairly elegant as workarounds go, but it still reeks of inheriting a CVS misfeature.) Have fun! ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net - 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
