They were off by a factor of 10 with the likelihood of being struck and killed by lightning, according to the nws website. To clarify: the likelihood of being merely struck by lightning is ~ 1/1,000,000 per year. The likelihood of being struck and killed is 1/10,000,000 , or about 1/2^23.25 Given this, you would only have to be struck and killed by lightning 6.8 years in a row to equal a sha1 hash collision probabili…
Git 2.11 has been released
61–68 of 68 posts
Re: Git 2.11 has been released
#62They were off by a factor of 10 with the likelihood of being struck and killed by lightning, according to the nws website. To clarify: the likelihood of being merely struck by lightning is ~ 1/1,000,000 per year. The likelihood of being struck and killed is 1/10,000,000 , or about 1/2^23.25 Given this, you would only have to be struck and killed by lightning 6.8 years in a row to equal a sha1 hash collision probabili…
More importantly, the comparison is useless. The odds of running into issues with SHA-1 collisions in Git is a very different question from just the odds of two random SHA-1 hashes colliding.
Re: Git 2.11 has been released
#63Earlier quoted context omitted.
Regarding Base 32, I love the justification used for removing U. I, L, and O all have potential confusion with digits, but U was removed because of "Accidental obscenity".
I'm surprised it wasn't just "and all vowels" with the same reasoning, or at least 'a' (because I can more readily think of examples than for, say, 'e'). I suppose, though, there's an attraction in using b32 rather than b29... (Though I notice mid-word apostrophes are double-tap-selectable at least on macOS, so perhaps swapping 'a' for ''' would be advantageous, if more complicated to explain.)
Re: Git 2.11 has been released
#64Jesus christ Git's interface design is horrible. Master Coder: Hmm. We refer to changes by a long, totally non-human-parseable string of characters that nobody can memorize, and when we abbreviate it, it doesn't work 100% of the time. What can we do about it? Novice Apprentice: Well... how about we stop using a long totally non-human-parseable string of characters that no human can can memorize just to briefly refer…
> Git is full of some of the worst design decisions in modern software history. It's also full of some of the best software design decisions. The internals of Git are simple and elegant and they work like a charm. There have been very little changes to the internal workings since the first commit of Git. I agree that the user interface is inconsistent, ugly and hard to grasp. But if you have a solid understanding of…
You should not have to understand the design of the modern combustion engine to operate a car. You shouldn't even have to understand bicycle geometry to ride a bike. It's a friggin tool!
Why on earth would you want to have to become a master of the design of a tool to use it? The whole point of making a complicated tool is to make your life easier! No other revision control system is this complicated and annoying. And i'm not going to quit whining, it sucks and it's stupid and it doesn't have to be, and people keep worshipping it like it's this amazing invention like nobody's heard of a merkle tree before. It treats chunks of changed text like blobs, wow, nobody's done that before. Oh a collection of packed objects, how novel.
By the way, the internals aren't that great either. You have to constantly "clean" your repository as it collects useless crap, merges become such a headache you're asked to destroy your merges to make it somewhat sane to maintain, handling "large" objects is a mystery to us, and the entire design is intended to interface with others and yet it's designed as if your personal repo were the only repo in the universe. You have to use a dozen filters and options and processes to do what a single script could do if it asked you what you wanted to get done, but we have to literally sacrifice a goat on the mountain of Unix Philosophy in order to get something done and go back to doing real work.
Why does it force us to send these anonymous patches and not allow merges to happen intelligently among a group using locks? Why does it force a maintainer to do all the work of managing patches? Why does it waste local storage when we don't need 99% of the repository most of the time? Why can't log messages and status be rendered in a quasi-usable way, or, heaven forbid, we have a Curses frontend for the myriad of random chunks of text and commands we have to memorize to accomplish one small simple operation? Why does the repository fall apart into a completely unusable mess if you don't weed it once a day? Why do we have to shuffle around a bunch of commands to perform a single simple task that any reasonable program 15 years ago would have done for you?
Answer: Because the design is crap. If people would at least just admit the design is crap, I would stop whining. But at this point I feel like i'm the only sane human in a world full of people doing the work for the robots and smiling about how much easier their lives are now.
Re: Git 2.11 has been released
#65Earlier quoted context omitted.
I'm surprised it wasn't just "and all vowels" with the same reasoning, or at least 'a' (because I can more readily think of examples than for, say, 'e'). I suppose, though, there's an attraction in using b32 rather than b29... (Though I notice mid-word apostrophes are double-tap-selectable at least on macOS, so perhaps swapping 'a' for ''' would be advantageous, if more complicated to explain.)
The two "worst" swearwords that pop into mind both have "u" in them. Meanwhile, the swears with "a" in them seem to be the tamest of the lot.
Regardless of variance, I don't think I'd regard either the above or the name of a fat character in Austin Powers as "tamest of the lot".
Re: Git 2.11 has been released
#66Earlier quoted context omitted.
The two "worst" swearwords that pop into mind both have "u" in them. Meanwhile, the swears with "a" in them seem to be the tamest of the lot.
"Tameness" varies extraordinarily by region - an infamous example being 'twat' which throughout the UK ranges from friendly to vulgar. Regardless of variance, I don't think I'd regard either the above or the name of a fat character in Austin Powers as "tamest of the lot".
Re: Git 2.11 has been released
#67My name is Angela and I do research for Bitbucket. I’m kicking off a round of discussions with people who use Git tools. Ideally, I’d like to talk to people that sit on a team of 3 or more. If this is you, I would love to talk to you about your experience with Git tools, or just some of the pain points that are keeping you up at night when doing your jobs.
We’ll just need 30 mins of your time, and as a token of my thanks to those that participate, I’d like to offer a US$50 Amazon gift voucher.
If you’re interested, just shoot me an email with your availability over the next few weeks and we can set up a time to chat for 30 minutes. Please also include your timezone so we can schedule a suitable time (as I’m located in San Francisco). Hope to talk to you soon!
Cheers, Angela Guo aguo@atlassian.com
Re: Git 2.11 has been released
#68Earlier quoted context omitted.
That piqued my curiousity, and I had to dig up the relevant commit: https://github.com/git/git/commit/bb84735c80 . It deals with wrapping an integer index around after incrementing it, the old code just used ++index and a bitmask, the new code uses + 1 and modulo. I have problems understanding this right now, in my world ++index for an int really shouldn't trigger overflow when counting to at most 4, on any (sem-)rea…
The counter never resets, it just keeps going up and we only look at the low bits. So eventually it will need to wrap. It's doubtful that ever happened in practice, even on a 32-bit system (you'd need to print 2 billion SHA-1s in a single process, and even the largest repos have on the order of millions). So the key difference between the old and the new is that the counter resets to zero every fourth call.