Git 2.11 has been released
github.com
Git 2.11 has been released
1–10 of 68 posts
Re: Git 2.11 has been released
#2I'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.
Re: Git 2.11 has been released
#3What a great writeup.
Re: Git 2.11 has been released
#4This 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...
Re: Git 2.11 has been released
#5Hexadecimal 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
Re: Git 2.11 has been released
#6I'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.
Yeah, I guess dates are only available for commits but not blobs or trees.
This is suggested by the disambiguation listing; if there were dates they would be displayed I hope.
I think approximate dates might be inferred, but since it might be misleading and costlier to determine it makes sense to leave it out - at least in this version of git.
Re: Git 2.11 has been released
#7I'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.
Yeah, I guess dates are only available for commits but not blobs or trees. This is suggested by the disambiguation listing; if there were dates they would be displayed I hope. I think approximate dates might be inferred, but since it might be misleading and costlier to determine it makes sense to leave it out - at least in this version of git.
[deleted]
Re: Git 2.11 has been released
#8Converting to and from base 36 (or 32) would probably do more to help the problem than any heuristics. Compare:
66c22ba6fbe0724ecce3d82611ff0ec5c2b0255f
c04bo5604v5qsp6asgasjp9y4paxu8v
Re: Git 2.11 has been released
#9I'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.
Dates are available for some objects, see http://stackoverflow.com/a/39930978/1832154 for more details about what is/isn't available.
The issue is a different one, I believe you're considering one specific situation while there are others to ponder. What would happen if someone copy & pasted part of the hash, or had some tool that always reduced that output to the first few digits, or other situations like these, how would you be able to tell that the user was actually after the oldest commit? It seems much easier to indicate there's a problem, a conflict, and let the user solve it.
Re: Git 2.11 has been released
#10Great 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...