3 ms·

I think what you're pointing out is an example of a real problem. I'm not sure the problem has a name or is noticed by most people. But something is off. In som

I think what you're pointing out is an example of a real problem. I'm not sure the problem has a name or is noticed by most people. But something is off. In some cases it might be that common conventions (like dotfiles) aren't really well-designed. But I think the more general issue is that the current set of abstractions (file/directory/symlink) are not sufficient to take good care of practical use cases we have for data these days, not matter how cleverly we use them. Should .git directory reside in the same directory as your source code? Maybe not. Fossil has an interesting compromise in that regard. Should compiled artefacts reside in the same directory as your source code? Almost certainly not. This seems like a bad idea from some hacky implementation decades ago. Should tools be able to distinguish between "real" files and metadata files? Almost certainly yes, except there are different types of "metadata" files, as you pointed out. I think naming conventions are simply not good enough to handle this properly. This is where FS metadata could come into play. Generally, I think if someone without prejudice examined the common problems we have with data these days and designed a "file" system from scratch, they would end up with something vastly different from our current files/folders paradigm.

klabb3 4y ago
> Should .git directory reside in the same directory as your source code? Maybe not. Indeed, many dependency managers (both go mod and cargo iirc) don't vendor deps into your working dir. > I think naming conventions are simply not good enough to handle this properly. This is where FS metadata could come into play. Yeah, the ideal solution may be just that, but I'm not 100% convinced that dirname conventions and tooling can't solve the major hurdles. New file systems would take decades even if they were to take on.. And for VCS and other tools you need to account for many different file systems and can't rely on anything but largest-common-denominator features..

klabb3 4y ago

> Should .git directory reside in the same directory as your source code? Maybe not. Indeed, many dependency managers (both go mod and cargo iirc) don't vendor deps into your working dir. > I think naming conventions are simply not good enough to handle this properly. This is where FS metadata could come into play. Yeah, the ideal solution may be just that, but I'm not 100% convinced that dirname conventions and tooling can't solve the major hurdles. New file systems would take decades even if they were to take on.. And for VCS and other tools you need to account for many different file systems and can't rely on anything but largest-common-denominator features..