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

Git's initial commit

github.com

Post reply on HN
Print view View original

111–120 of 128 posts

Re: Git's initial commit

#111

Post by mushishi »

sytelus wrote: post #79
guelo wrote: post #51

Earlier quoted context omitted.

I consider that a bug in their style spec. Single line if statements are known to cause bugs.

That's what I'd thought for may be over a decade. About ~3 years ago I revamped my personal coding style to eliminate as unnecessary baggage as possible. As part of that I stopped using braces for single line if and I'd yet to bump in a bug because of that. Overall I find code looks more compact and cleaner, may be even less friction to read. Nowadays when I see a braces around single line if I get that "oh that's cl…

I nowadays resist the urge to make syntactically beautiful code if that means that it is a little bit brittle or vulnerable to mistakes.

Wrt. using { }, I omit them if I put the block to be executed on the same line, and usually I do that only with special cases, e.g.

  if(expr1) continue;

  if(expr2) throw new RuntimeException();

Re: Git's initial commit

#115

Post by scintill76 »

dlitz wrote: post #104
scintill76 wrote: post #85

Earlier quoted context omitted.

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

> Maybe I'm being too mean, but yeah, I also think a lot of the comments are pointless. Yeah, I think you're being a little mean. If you browse to that user's GitHub page, it looks like it's just somebody new who's excited about software. Good for them. The comments are pointless, sure, but also harmless. Similar comments might crowd out productive discussion if they were on (say) the head of the master branch, but I…

Yeah, fair enough. Good on you for linking your own cringey post. I think a lot of developers have those early cringe moments, especially if they were young when they started.

As far as disruption, it did occur to me later that somebody may be getting notification emails about these comments. But it's not too bad, as I assume they could just send the emails to /dev/null, since Github is not the official host of git. (As a tangential note, I sort of wish Github would handle this better. So many Github-mirrored projects end up with something like "don't submit pull requests or open issues here, they will be ignored" in their repo description.)

Re: Git's initial commit

#116

Post by PurplePanda »

pdw wrote: post #78
PurplePanda wrote: post #66

Earlier quoted context omitted.

It confuses me that it doesn't work for functions. like int main() return 0;

In K&R C, the function braces serve to separate parameter declarations and local variables: int main(argc, argv) int argc; char **argv; { int local; }

Thanks, I haven't seen that syntax before.

Re: Git's initial commit

#117

Post by throw_away »

pja wrote: post #88
EGreg wrote: post #84

Linus 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 arbitr…

In particular he's saying that for a tree, you can quickly skip sub-trees if they are the same, regardless of how deep they go. Kind of like a Merkle tree: http://en.m.wikipedia.org/wiki/Merkle_tree

I'm no git internals expert, but I suspect for a flat list of files the complexity is still O(n) where n is the number of files (not changes) because at very least you must check that n checksums are the same.

Re: Git's initial commit

#118

Post by EGreg »

pja wrote: post #88
EGreg wrote: post #84

Linus 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 arbitr…

Wouldn't it still be O(total)? Or at the very least O(log total)? You have to look at all the files even if it's just to compare the hash. The size of the file doesn't matter so I think what Linus should have said was it's O(number of files) still, and maybe O(log total) in the average case. But if there are 1,000,000 files and only 2 change then I don't see how you don't have to look at all the hashes.

Re: Git's initial commit

#119

Post by EGreg »

coldpie wrote: post #108
jordigh wrote: post #36

Well, while we're looking at FIRST POSTS, here's Mercurial's, self-hosting a month after git, and like git, also created to replace bitkeeper: http://selenic.com/hg/rev/0#l10.1 The revlog data structure from then is still around, slightly tweaked, but essentially unchanged in almost a decade.

Mercurial is impressive for making Git's UI look intuitive.

Other way around

Re: Git's initial commit

#120

Post by pja »

throw_away wrote: post #117
pja wrote: post #88

Earlier quoted context omitted.

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 arbitr…

In particular he's saying that for a tree, you can quickly skip sub-trees if they are the same, regardless of how deep they go. Kind of like a Merkle tree: http://en.m.wikipedia.org/wiki/Merkle_tree I'm no git internals expert, but I suspect for a flat list of files the complexity is still O(n) where n is the number of files (not changes) because at very least you must check that n checksums are the same.

I'm no git internals expert, but I suspect for a flat list of files the complexity is still O(n) where n is the number of files (not changes) because at very least you must check that n checksums are the same.

Sure. The constant factors make a huge difference though - even if you've cached all the data in memory walking all those structures and diffing the actual file data is going to be enormously slower than simply walking a list of hashes, so you're really saying that the total time is big * O(number of files changed) + small * O(number of files). If small*N ~ big then it's reasonable to just disregard that cost - it's going to be lost in the noise.

Post reply on HN