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

Introducing Git protocol version 2

opensource.googleblog.com

Post reply on HN
Print view View original

111–120 of 167 posts

Re: Introducing Git protocol version 2

#111

Post by cesarb »

stingraycharles wrote: post #47
icebraining wrote: post #42

Earlier quoted context omitted.

It's an universal truth: if you want to keep something from jamming up, you need to exercise it. It's true for the human body, for machine parts and for protocol features.

HTTP was at 1.1 for a very long time but it appears the upgrade to version 2 is going fine. What is the difference here? The protocol version exchange mechanism?

The main difference is that a "side channel" of the TLS connection (the NPN or ALPN extensions) is used to negotiate HTTP/2. The upgrade to version 2 without the TLS wrapper failed; so many servers and/or middleboxes had issues with it, that all browser makers decided "HTTP/2 is going to be TLS only" (the current "encrypt all the things" push played a small part, but the main reason was the compatibility problems).

Re: Introducing Git protocol version 2

#112

Post by spc476 »

jburgess777 wrote: post #105
bluejekyll wrote: post #61

Earlier quoted context omitted.

DNS has no version field. I'm torn as to the choice here. On the one hand, DNS is backwards compatible with everything. EDNS is the only way to extend the protocol now, which is basically just adding additional Records to the Message that are designated as Extended DNS records, and treated specially.

The IETF is working on a document which describes many reasons why DNS may stop working. EDNS related issue are in section 3.2: https://tools.ietf.org/html/draft-ietf-dnsop-no-response-iss...

My own code to decode DNS packets [1] fell afoul of section 3.1.3 of the draft document. I fixed the issue, but the reason I originally rejected DNS packets with unknown flags was on the assumption of potential garbage being used as a possible exploit.

[1] https://github.com/spc476/SPCDNS

Re: Introducing Git protocol version 2

#113

Post by nkkollaw »

loeg wrote: post #91
fiatjaf wrote: post #89

Earlier quoted context omitted.

That may seen odd, but it could happen in a open-source world: multiple parties releasing different versions of the same piece of software and calling it the same.

One fun example of this is the so-called RPM "5" fork[0], which is basically dead and almost entirely unused[1]. The result is the main RPM everyone uses will probably stay at version 4.x forever. [0]: http://rpm5.org/ [1]: https://en.wikipedia.org/wiki/Rpm_(software)#RPM_v5

They could skip a version like PHP did. Among other reasons, since books and articles about PHP 6 had already been written long before PHP 5+1 came out, they went with 7.

Re: Introducing Git protocol version 2

#114

Post by vatueil »

skywhopper wrote: post #107
AdmiralAsshat wrote: post #76

Earlier quoted context omitted.

Thanks, that really helps. As an open-source advocate, my first thought was, "Why the hell is Google releasing a version of a protocol that Linus Torvalds wrote?" Without that context, it would be like Google throwing up an announcement, "Introducing Google's Linux Kernel 5.0!"

Yeah, that was my reaction, and it made me sad that Google has so eroded my trust over the decades that I was turned off at seeing an announcement implying they are deeply involved in core open source tools. I mean, who else but companies swimming in cash can truly deeply support this stuff, and for the most part, the people working on these tools really do care about the open source community. But Google's reputatio…

I wasn't aware that the maintainer of Git works at Google, so I was a bit surprised by the announcement too. But it wasn't because of any drama like Google eroding my trust or whatnot, just that my information was incomplete so my gut reaction was irrational.

Re: Introducing Git protocol version 2

#115

Post by sevensor »

brown9-2 wrote: post #83
castis wrote: post #75

Earlier quoted context omitted.

Most likely it was noted because several of us probably immediately wondered why google would have taken it upon themselves to release a new version of something they weren't the maintainer of.

Google has as much incentive as anyone else to introduce a faster wire protocol. The article mentions the Chrome project, and don’t forget that Google Cloud has a git-repo-hosting product.

That's true, and while we all get to enjoy the new protocol, it seems like its primary beneficiary will be big organizations that have gigantic repos with massive numbers of refs in them. Furthermore, there's a clear orientation towards specialization -- putting that giant repo on a central server. Google clearly stands to benefit more from this work than those of us who use git as a distributed version control system. Who pays the piper calls the tune.

Re: Introducing Git protocol version 2

#116

Post by loeg »

nkkollaw wrote: post #113
loeg wrote: post #91

Earlier quoted context omitted.

One fun example of this is the so-called RPM "5" fork[0], which is basically dead and almost entirely unused[1]. The result is the main RPM everyone uses will probably stay at version 4.x forever. [0]: http://rpm5.org/ [1]: https://en.wikipedia.org/wiki/Rpm_(software)#RPM_v5

They could skip a version like PHP did. Among other reasons, since books and articles about PHP 6 had already been written long before PHP 5+1 came out, they went with 7.

Sure, they could. I don't think they've felt the need to. RPM tends to change slowly and conservatively.

Re: Introducing Git protocol version 2

#117

Post by sdesol »

hk__2 wrote: post #23
cpburns2009 wrote: post #12

Wait, why was this posted by Google? I thought Git was made by Linus Torvalds.

Git was created by Linus Torvalds, but out of the 50k+ commits on the repo, only 250 or so are from him, with only 14 in the past 6 years. [1] [1] https://github.com/git/git/graphs/contributors?from=2012-03-...

Here is a more detailed analysis, which shows all contributors:

https://public.gitsense.com/insight/github?r=git/git#b%3Dgit...

These are contributions by Linus:

https://public.gitsense.com/insight/github?r=git/git#b%3Dgit...

and as you can see, his contributions, really tapered off after 2010, while contributions from Hamano remained steady from 2008 to present date, as shown below:

https://public.gitsense.com/insight/github?r=git/git#b%3Dgit....

Re: Introducing Git protocol version 2

#118

Post by shakna »

gpvos wrote: post #56
zeroxfe wrote: post #9

Earlier quoted context omitted.

Or, more likely, an oversight.

Hmm, I haven't designed very many data formats or wire protocols, and I won't claim I got it right any of those times, but I included some kind of extension possibility every time.

Git was a 10-day urgent project. Given the timeframe, it's done remarkably well.

Re: Introducing Git protocol version 2

#119

Post by harveynick »

falsedan wrote: post #96
harveynick wrote: post #72

Earlier quoted context omitted.

Yes and no. The answer is actually quite complicated... and I have no idea if I'm allowed to talk about it publically or not.

Then don't waste peoples time with vacuous comments.

Ironic reply.

Sincere apologies if you can't derive any information from my comment, but that doesn't mean there isn't any there.

Re: Introducing Git protocol version 2

#120

Post by harveynick »

harveynick wrote: post #72
kardianos wrote: post #35

Earlier quoted context omitted.

Gerrit is a review server that uses git. In fact, Gerrit now stores the majority of information in git itself for all the information it uses. So for Google external projects, they use git. > Although given Google's scale, I'm sure there's some teams/projects that use Mercurial. I doubt it. Their tooling is probably pretty specific, and now that code.google.com has shut down, they probably don't have any review serve…

Yes and no. The answer is actually quite complicated... and I have no idea if I'm allowed to talk about it publically or not.

The most recent reason public reference I can find to this is from 2016: https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...

Here's the money quote:

"The team is also pursuing an experimental effort with Mercurial an open source DVCS similar to Git. The goal is to add scalability features to the Mercurial client so it can efficiently support a codebase the size of Google's. This would provide Google's developers with an alternative of using popular DVCS-style workflows in conjunction with the central repository. This effort is in collaboration with the open source Mercurial community, including contributors from other companies that value the monolithic source model."

Project that forward logically by two years.

Post reply on HN