Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git 2.11 has been released

github.com

Post reply on HN
Print view View original

41–50 of 68 posts

Re: Git 2.11 has been released

#41

Post by mikeash »

eridius wrote: post #31
joallard wrote: post #27

Earlier quoted context omitted.

Case-insensivity is important for some to be able to reliably remember a string. I won't easily retain the difference between 'b4dQbFs31' and 'b4DqBfs31'. Same thing when speaking it out loud. 'B four D capital Q B capital F s thirty-one' is way more convoluted and error-prone than 'B four D Q B F S thirty-one'. The best thing I've found that fits this criterion is Crockford's Base 32 [1], basically the extension of…

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 once had a moment of panic after coming up with and shipping a custom scheme along these lines, when I realized there was a decent probability of generating accidental profanity. Afterwards I came up with a filter, and we spent a fun day filling it with every nasty word we could think of.

Re: Git 2.11 has been released

#42

Post by boundlessdreamz »

kannonboy wrote: post #10

Great write-up! I love the focus on performance in this release. I've put together another write-up of the Git 2.11 release that discusses some of the other new features (and goes into a little more detail on some of the 'sundries'): https://medium.com/@kannonboy/whats-new-in-git-2-11-64860aea...

Great writeup! Btw what tool did you use to make the merge diagrams?

Re: Git 2.11 has been released

#43

Post by kannonboy »

boundlessdreamz wrote: post #42
kannonboy wrote: post #10

Great write-up! I love the focus on performance in this release. I've put together another write-up of the Git 2.11 release that discusses some of the other new features (and goes into a little more detail on some of the 'sundries'): https://medium.com/@kannonboy/whats-new-in-git-2-11-64860aea...

Great writeup! Btw what tool did you use to make the merge diagrams?

Thanks! Just Keynote & GIMP on macOS

Re: Git 2.11 has been released

#44

Post by OJFord »

eridius wrote: post #31
joallard wrote: post #27

Earlier quoted context omitted.

Case-insensivity is important for some to be able to reliably remember a string. I won't easily retain the difference between 'b4dQbFs31' and 'b4DqBfs31'. Same thing when speaking it out loud. 'B four D capital Q B capital F s thirty-one' is way more convoluted and error-prone than 'B four D Q B F S thirty-one'. The best thing I've found that fits this criterion is Crockford's Base 32 [1], basically the extension of…

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

#46

Post by beagle3 »

joallard wrote: post #27
atemerev wrote: post #5

Hexadecimal dumps of binary data are the worst of all worlds if used as keys/references. Hard to memorize, hard to type, look ugly, aren't compact. Better alternatives: Base64 without padding: compact. Grouped decimals: slightly less compact than hexadecimal, but extremely easy to type and pronounce. E.g. 577-467-341-467

Case-insensivity is important for some to be able to reliably remember a string. I won't easily retain the difference between 'b4dQbFs31' and 'b4DqBfs31'. Same thing when speaking it out loud. 'B four D capital Q B capital F s thirty-one' is way more convoluted and error-prone than 'B four D Q B F S thirty-one'. The best thing I've found that fits this criterion is Crockford's Base 32 [1], basically the extension of…

The best way to use words that I've seen (e.g., over the phone, and also to memorize) is Mnemonicode, originally created by Oren Tirosh, who has since abandoned it, but there are multiple compatible versions all around, see e.g. [0].

Unfortunately, most of the references around the web link to Tirosh's original work on the WayBack machine, which used to be hosted on "tothink.com", but the new owners put a "robots.txt" which make even the old version unaccessible on archive.org

[0] https://github.com/singpolyma/mnemonicode

Re: Git 2.11 has been released

#47

Post by cakoose »

godson_drafty wrote: post #21

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…

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

#48

Post by nhaehnle »

algesten wrote: post #45

Why doesn't git upon commit ensure the sha-1 is unique by having some nonce as part of it? I guess if you only work with rebases instead of merges, it should be possible, right?

It would defeat the purpose of a content-addressable storage system. The fact that the same file and the same tree will always have the same hash is important for speeding up diffs, merges, and other operations.

Re: Git 2.11 has been released

#49

Post by bonzini »

shakna wrote: post #35
MBCook wrote: post #11

It's been a while since I looked into what Git was up to in the latest version. The release notes mentioned protocol improvements with git-filter that can dramatically speed up git-LFS (the large file storage plugin). Does anyone know if there are any plans to make git-LFS part of the base instead of an add on?

I'd assume there's licensing issues before anything else: git-lfs is MIT licensed, git GPLv2.

It's a compatible license, so it's not an issue.

Re: Git 2.11 has been released

#50

Post by chriscool »

MBCook wrote: post #11

It's been a while since I looked into what Git was up to in the latest version. The release notes mentioned protocol improvements with git-filter that can dramatically speed up git-LFS (the large file storage plugin). Does anyone know if there are any plans to make git-LFS part of the base instead of an add on?

There is work going on about external object database support that could help in the long run:

https://github.com/git-lfs/git-lfs/issues/1702

(I am working on this for GitLab.)

Post reply on HN