This is a great lesson in writing focused & succinct specs, when one clearly sees what his/her program is going to do.
Git's initial commit
81–90 of 128 posts
Re: Git's initial commit
#82Earlier quoted context omitted.
I was under the impression that git hashes are generated based on the contents in a commit. If that's true you cannot retire them. They're not random.
While that is true, part of the contents that is hashed is the time of commit. Therefore if you (somehow...) managed to get that hash, you could just reset and commit again. Or amend. In any case, I believe he was joking. The odds of a sha1 collision are very very low.
Very low indeed. Chance of SHA1 collision is of the order of 2^52. One person explained it this way: Chance of everyone currently on Earth winning a jackpot in their lifetime is actually higher than a single random SHA1 collision. It should be actually mind boggling how many of the software systems and algorithms rely on hashes and them being not collided.
Re: Git's initial commit
#83My god... the comments. Looks like the reddit culture (i.e. fun for in jokes but not particularly professional)
Re: Git's initial commit
#84Linus wrote:
* +Side note on trees: since a "tree" object is a sorted list of +"filename+content", you can create a diff between two trees without +actually having to unpack two trees. Just ignore all common parts, and +your diff will look right. In other words, you can effectively (and +efficiently) tell the difference between any two random trees by O(n) +where "n" is the size of the difference, rather than the size of the +tree. *
Um, What?
Re: Git's initial commit
#85My god... the comments. Looks like the reddit culture (i.e. fun for in jokes but not particularly professional)
"A marathon of clicking 'next page,' but the view is worth it." So, this commenter practically worships git, but apparently doesn't actually understand it well enough to know a better way to find the hash of the first commit and punch that into Github. Or, it was just a joke and they got there the quick way, but still felt obliged to post a dumb joke to inflate their own ego by "leaving their mark" on git. Maybe I'm being too mean, but yeah, I also think a lot of the comments are pointless.
Re: Git's initial commit
#86Earlier quoted context omitted.
It's pointless to argue over these kind of things. Every major project/company has their own codified code style guide, and if you want to contribute/earn your salary then you must follow that style guide to the T. Here's the relevant quote from the Linux kernel coding style[0]: Do not unnecessarily use braces where a single statement will do. if (condition) action(); [0] https://www.kernel.org/doc/Documentation/Codi…
You can sidestep the braces debate by using a lisp.
To introduce Lisp you need to fight the parens debate instead ...
Re: Git's initial commit
#87It's so short. The readme is the best explanation of git I've seen.
Does anyone know if the structure of git has changed much? I would like to read this thinking this is pretty close to the current implementation but I would have no idea. anyone?
It seems to be mostly the same, except that "Changeset" is now called "Commit" and "Current directory cache" is now called "index", but they are functionally the same.
It's actually really great to see that the model hasn't changed much (there must have been a long phase of thinking before though)
If you want to go deeper, you can check out this page:
Re: Git's initial commit
#88Linus wrote: * +Side note on trees: since a "tree" object is a sorted list of +"filename+content", you can create a diff between two trees without +actually having to unpack two trees. Just ignore all common parts, and +your diff will look right. In other words, you can effectively (and +efficiently) tell the difference between any two random trees by O(n) +where "n" is the size of the difference, rather than the siz…
Since a git hash points to a sorted list of filenames and content hashes, to diff two git commits you lookup the commit objects by their hash, run down the resultant list of filename/hash pairs & then only lookup & diff the content of those files that have differing hashes (if they have the same hash, they must have the same content according to the git data model, so they can be safely ignored).
Hence diffing arbitrary commits with git is always O(N) in the number of changed files, regardless of the number of interstitial commits.
Re: Git's initial commit
#89Re: Git's initial commit
#90Did all of the inital commit code is written by Linux Torvalds ?