= 27d567bc2d48d9f40e9ccc20ea370b15)
wedrifid comments on Tool ideology - Less Wrong
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (66)
Doesn't work so well if the content is 'nothing'.
Git doesn't notice these at all.
Which is my point exactly. It is one aspect of Vi's criticism of git not storing some important data that is clearly valid. It is a tradeoff that probably doesn't matter if you are Linus and you are storing code for a Linux kernel but in other cases it is a blatant flaw that needs to be worked around via compromises or kludges.
Git is the absolute worst version control system out there (except for all the others).
In what situations would you want to store an empty directory and pay attention to whether it is renamed?
Empty directories are sometimes necessary and it's a pain in the ass that git cannot store them at all. I had to put almost empty README.txt files in directories like log/ in many projects. It's more a minor annoyance than anything more.
I have a complex enough deployment helper living in Monotone repository for which it is simpler and more natural to keep a few empty directories in the repository than to check-and-create from each of ten shellscripts. It is checkout-and-use, no other setup makes sense, so "just creating them in Makefile" would be suboptimal.
A single line of:
will deal with it. It's a nice idempotent action. I started using
mkdir -pas workaround forgitissues, but now it just seems to make far more sense than dicking around manually maintaining working directories.I know about "mkdir -p" - my non-problem (I was not going to use Git anyway for this project) is that I multiple places where to put it and if I miss one I will not notice for some time.
Saying that recreating something just in case right after checking out the new version makes more sense than simply storing along with all the rest seems to be exactly an example of tool imposing some workflow ideas on people.
You have it backwards. Using version control to store working areas for programs rather than programs simply
mkdir -ping working areas they need seems to be exactly an example of tool imposing some workflow ideas on people.I'm mostly serious here.
You're mostly wrong. Enough so that I reread your comment 4 times to be sure I was parsing correctly.
I have two choices, you have one. My tool imposes less workflow ideas here. It's totally information-theoretical.
There are so many common cases where you absolutely need
mkdir -plike dynamic working directory layout that it's mentally simpler to just use it always. It works on 100% of problems, is idempotent, and resistant to human errors.Why would I ever bother with VCS-based solution what only works in some simple cases like static working directory layouts, is based on non-idempotent operations, and fails often in case of human mistakes?
It just creates so much less mental overhead if you simply
mkdir -pplace where you want to create your files always, no exceptions.I understand that people who use languages where
mkdir -pis a non-trivial operation won't get it, but that's problem with their tools limiting their mindset.Is that something I need a justification for? My version control system throws away stuff that I am trying store. I'd also prefer it not to throw away files staring with 'b'.
I've learned to make my programs pessimistic and recreate the file system if necessary. It surprised me a few times before I learned the quirks.
No, just curious. I have not encountered and could not imagine a use case.
Directories, in my mind, are meta-information about files, so it makes no sense to me to store an empty directory.
I may be missing context here, but I frequently create empty directories to guide future filing/sorting behavior.
The examples mentioned so far could be described as meta information about future intended files.