211–220 of 228 posts
Earlier quoted context omitted.
And the guy who announced the new Git release works for Google, but uses his pobox.com email for Git development.
Yes, actually, Googlers are encouraged to use their personal Github accounts.
Earlier quoted context omitted.
every UNIX and POSIX system that has been well-designed Case sensitivity wasn’t designed; the first Unix couldn’t spare the CPU cycles to do case insensitive matching, which was the norm at the time.
And yet nearly every UNIX system that was well-designed isn't case insensitive. I was pointing out correlation, not causation.
Earlier quoted context omitted.
The fact that Linux is case-sensitive is the egregious crime. It's a nasty holdover from circa-1970 Unix when case-folding was an expensive operation.
Case-senitivity is not a "nasty holdover", it is a good design decision that continues to be proven correct (case in point, this bugfix for case-insensitive filesystems). Why would you introduce complexity into the filesystem to try to normalize file names when you can simply, not? I mean, have you _seen_ the mess that is Unicode normalization? Hundreds of different glyphs or whatever that are all considered equivale…
Earlier quoted context omitted.
The two most difficult ones are naming things, cache invalidation, and off-by-one errors. HTH. ;)
I prefer the ordered version. three most difficult things in CS: 2) Naming Things 1) Cache Invalidation 4) off by one errors 3) Concurrency
0) naming things
1) cache invalidation
42) asynchronous callbacks
2) off by one errors
Earlier quoted context omitted.
It’s actually the hardest one of the three, being outside the grasp of formal methods.
I really have to disagree, why can't you devise a formal method? - a good name should be descriptive - avoid being overly clever, call a spade a spade - don't optimise for generalisation, naming things is a time to be specific - aim for short but not at the expense of losing context - avoid redundancy in naming of things nearby, leverage spatial context - avoid qualifiers or type information where possible - type sho…
The commit that fixes this issue: https://github.com/gitster/git/commit/684dd4c2b414bcf648505e... (Surprise, the root cause is a cache )
It's amazing how often exploits come down to optimizations. The general form being "the domain logic is X, and is secure, but we faked around it in this one case to make it faster, and it turns out we made a bad assumption while doing so". Meltdown fits this description too.
1. Make it work
2. Make it right
3. Make it fast (make sure you need to) a.k.a. optimize
4. Make it scale
Earlier quoted context omitted.
Ashamed to admit (as an OSX user) that I didn't even realize the FS was case-insensitive (having migrated from years of Linux usage to a non-Linux desktop). It does a good job of hiding this from the user (filenames are still listed with cases, and bash autocompletion completes to the correct case as well)
MacOS by default uses a "case-preserving case-insensitive" filesystem, so you can create files with mixed case, but you can't create two files with the same name and different case. It's one of MacOS's more-egregious crimes against Unix. Fortunately it doesn't manifest that often, but it rears its head often enough to be a problem.
Wait I'll try
...nope, after `touch makefile` and `touch Makefile`, I still see just `makefile`. OK
Earlier quoted context omitted.
But probably their work email when doing things on company time?
Nope. This is an example of someone working on company time using their personal email.
What's an easy way to fix the default git installation on OSX?
I did a `brew install git` and then deleted /Library/Developer/CommandLineTools/usr/bin/git. You can't delete /usr/bin/git even with sudo (system integrity policy). After installing git via brew and removing the one in CommandLineTools, /usr/bin/git is showing the latest version. me@local % git --version git version 2.30.2 I don't know if this is recommended or if it will have negative consequences that i don't know…