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

31–40 of 68 posts

Re: Git 2.11 has been released

#31

Post by eridius »

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…

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".

Re: Git 2.11 has been released

#32

Post by OJFord »

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…

    > 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 probability.
Oh, well that changes everything! ;)

Re: Git 2.11 has been released

#34

Post by peff »

kannonboy wrote: post #29
peff wrote: post #26

Earlier quoted context omitted.

That is a nice writeup. One of the interesting things for me was to see which topics you decided to cover and which to omit. For instance, I noted `clone --reference --recurse-submodules` as a potential topic of interest, but I am afraid to point anybody to the `--reference` option due to its hidden dangers. I'm also curious how you came up with 19,290 for a birthday paradox on a 7-hex hash. I think it's 16,384, but…

Thanks Peff, congrats on the great release! I came up with 19,290 using the generalized birthday formula[0] (actually after double-checking it's slightly closer to 19,291). 16,384 is the value you get using the square approximation method[1] which I believe is a bit less accurate in terms of probability, but faster to calculate. I think Git's using square approximation under the hood -- which is probably a good thing…

Right, I am so used to the square approximation being used for hash collisions that I forgot it was an approximation. Thanks for setting me straight.

Re: Git 2.11 has been released

#35

Post by shakna »

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.

Re: Git 2.11 has been released

#36

Post by farnsworth »

OJFord wrote: post #33

When a non-ambiguous short-hash _becomes_ ambiguous, can't it be disambiguated by simply disregarding those not in existence at time of reference?

Imagine if you merge a branch of old commits from another repo or something, which introduce short hash collisions. Then you copy/paste a short hash, and Git doesn't know when that reference is from or which branch it might refer to.

Re: Git 2.11 has been released

#37

Post by hossbeast »

based2 wrote: post #13
transfire wrote: post #8

Converting to and from base 36 (or 32) would probably do more to help the problem than any heuristics. Compare: 66c22ba6fbe0724ecce3d82611ff0ec5c2b0255f to: c04bo5604v5qsp6asgasjp9y4paxu8v That's approx a 25% gain in compactness.

https://github.com/thanatos/baseunicode

Interesting, I was hoping for an example at the end of the readme

Re: Git 2.11 has been released

#38

Post by deathanatos »

hossbeast wrote: post #37
based2 wrote: post #13

Earlier quoted context omitted.

https://github.com/thanatos/baseunicode

Interesting, I was hoping for an example at the end of the readme

(I'm the author.) That is an excellent suggestion. Now that you've mentioned it, it seems like a glaring omission. I'll try to fix that up once I get home.

In case the other parts of the README weren't clear, the concept was to use any Unicode character. I was even thinking of (eventually) getting it to encode data with combining accents. Note that it was intended to optimize the string for screen display space (pixels), not space.

I'm not sure it'd be a good fit for git hashes, simply b/c sometimes you need to type or speak a git hash, and the output from baseunicode was definitely not intended to be pronounceable. (Esp. since I was thinking of using CJK characters, but trying to weight them down for their wider screen area; but imaging trying to describe that to a co-worker who might only speak English.)

I wrote it mostly for fun, after I had a couple of difficult to transfer files between machines in the cloud. I find myself ssh'd into weird places, and scp'ing is sometimes trying. (I do machine-to-machine, so I almost always need -3, which I don't know why that isn't the default; scp doesn't deal well with the file being only accessible by root, not your user; scp has the weirdest arg syntax if you have ill-advised characters in your filenames, like spaces…) So I was cat'ing files, copying them from one window, and pasting into another window. base64 for binary data, tar/gzip for making it smaller. But for the copy/paste, scrolling is a pain, and heaven forbid if you're in screen/tmux.

(Also, if you find yourself really without a file that you can't scp, you can "re-implement" scp with `ssh $hosta sudo tar -cz | ssh $hostb sudo tar -xz`; see also the -C flag, and don't forget you can also `ssh $host "sudo bash -c 'cd /where && tar -cz '"`)

Re: Git 2.11 has been released

#39

Post by pitaj »

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".

That's actually pretty brilliant
Post reply on HN