11–20 of 68 posts
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?
This is a really well written partial set of release notes. I was curious and looked at the full release notes [1], and I think these are pretty well written as well. I'm very impressed, especially given that git has such a large set of contributors. [1]: https://github.com/git/git/blob/v2.11.0/Documentation/RelNot...
> The code that we have used for the past 10+ years to cycle 4-element ring buffers turns out to be not quite portable in theoretical world.
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.
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.
The only problem would by now probably too much code expects hex, so I'm not sure the gain is big enough to go through the pain of the switch.
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
In general, pure-number systems are better if possible, but where you have issues squashing in enough data in suitably compact form, transitioning to alphanumeric is better.
You can also consider the use prefix-based systems, either utilizing temporal epochs or node-specific prefixes, both of which can utilize readable aliases.
Finally, for anything expecting human transcription, checksum systems are awesome!
I'm curious but not motivated enough to really search for it, but for ambiguous hash abbreviations, why not select the oldest, since presumably it was unique at the time it was created? edit: I guess that information must not exist or I assume they'd be doing it.
It seems safer to just explicitly tell the user when they're trying to work with an ambiguous hash.
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
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
Still better is grouped alphanumeric without potentially ambiguous characters (ie. generate number-1's but not letter-I's, generate number-0's but not letter-O's). I wrote a disambiguation library based upon the checksums present in IBAN @ https://github.com/globalcitizen/php-iban .. it's surprising how accurate the mistranscription suggestions are. In general, pure-number systems are better if possible, but where yo…
This is a really well written partial set of release notes. I was curious and looked at the full release notes [1], and I think these are pretty well written as well. I'm very impressed, especially given that git has such a large set of contributors. [1]: https://github.com/git/git/blob/v2.11.0/Documentation/RelNot...