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

121–130 of 167 posts

Re: Introducing Git protocol version 2

#121

Post by SahAssar »

wmf wrote: post #59
stingraycharles wrote: post #47

Earlier quoted context omitted.

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 HTTP 1.1 to 2 upgrade is only going fine due to massive work (mostly by Google) over a period of years. HTTP/2 was also able to benefit from a lot of pain that SPDY and WebSockets went through earlier. Protocol ossification is still a hard problem.

IIRC WebSockets has basically nothing to do with the way http2 is handled, and websockets are still going over a simple HTTP1.1 Connect/Upgrade. What is the connection between websockets and http2?

Re: Introducing Git protocol version 2

#122

Post by wmf »

SahAssar wrote: post #121
wmf wrote: post #59

Earlier quoted context omitted.

The HTTP 1.1 to 2 upgrade is only going fine due to massive work (mostly by Google) over a period of years. HTTP/2 was also able to benefit from a lot of pain that SPDY and WebSockets went through earlier. Protocol ossification is still a hard problem.

IIRC WebSockets has basically nothing to do with the way http2 is handled, and websockets are still going over a simple HTTP1.1 Connect/Upgrade. What is the connection between websockets and http2?

Early version of WebSockets exposed bugs in HTTP proxies, some of which were security problems: http://www.adambarth.com/papers/2011/huang-chen-barth-rescor... To fix these kinds of problems, the final version of WebSockets does not use a straightforward upgrade but instead has a kludgey handshake and content masking: https://en.wikipedia.org/wiki/WebSocket#Protocol_handshake https://trac.ietf.org/trac/hybi/wiki/FAQ

HTTP/2 doesn't have the same problems because it requires TLS+ALPN, but IIRC that "clean" solution was only arrived at after years of discussion and experimentation.

Re: Introducing Git protocol version 2

#123

Post by netheril96 »

trumped wrote: post #64
oneeyedpigeon wrote: post #15

The current (and pretty much only, ever, despite Linus having been the creator) maintainer of git is a google employee [1], in case anyone else was wondering. [1] https://en.m.wikipedia.org/wiki/Junio_Hamano

Does he do it as a Google employee or on his own time? If he does it on his own time, why does it matter that he works at Google? and If he does it as a Google employee, when are the ads coming? edit: 3 replies, 5 down-votes and no answer to the main question...

I guess others downvote you because your insinuation about how Google will sneak ads into an open source project. They've never done that before, so it is rather odd accusation.

Re: Introducing Git protocol version 2

#124

Post by willnorris »

ojosilva wrote: post #30
oneeyedpigeon wrote: post #15

The current (and pretty much only, ever, despite Linus having been the creator) maintainer of git is a google employee [1], in case anyone else was wondering. [1] https://en.m.wikipedia.org/wiki/Junio_Hamano

Alright, I was wondering why this was published on the Google Opensource website. I had no idea. Yet, the Git project itself has not been published under their umbrella. https://opensource.google.com/projects/list/featured

We currently only list project that are or were primarily developed by Google. We decided to include projects that started at Google and were since donated to foundations, such as Kubernetes.

But we aren't yet including projects where we are just heavy contributors, but they're not "Google projects". That includes Linux, git, LLVM, and a host of others. We do want to recognize them in our project directory, but want to make sure that they are distinguished from Google projects so that we're not implying something that is accurate.

Re: Introducing Git protocol version 2

#125

Post by eridius »

Someone1234 wrote: post #22

Too bad they didn't make Git LFS part of Version 2[0]. Most vendors[2] support LFS already but because it isn't required, some still lack it and its support cannot be assumed. [0] https://git-lfs.github.com/ [1] https://github.com/git-lfs/git-lfs/wiki/Implementations

Requiring Git-LFS support would be rather problematic for anyone who self-hosts git repos over SSH.

Re: Introducing Git protocol version 2

#126

Post by auscompgeek »

sevensor wrote: post #115
brown9-2 wrote: post #83

Earlier quoted context omitted.

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

In all fairness, GitHub also has much to benefit from this too, playing host of the Mozilla git mirror, which also has a relatively large number of refs: https://github.com/mozilla/gecko-dev

Re: Introducing Git protocol version 2

#127

Post by Someone1234 »

eridius wrote: post #125
Someone1234 wrote: post #22

Too bad they didn't make Git LFS part of Version 2[0]. Most vendors[2] support LFS already but because it isn't required, some still lack it and its support cannot be assumed. [0] https://git-lfs.github.com/ [1] https://github.com/git-lfs/git-lfs/wiki/Implementations

Requiring Git-LFS support would be rather problematic for anyone who self-hosts git repos over SSH.

They'd just stick to Protocol 1

Re: Introducing Git protocol version 2

#128

Post by paxy »

pritambaral wrote: post #99
paxy wrote: post #86

Earlier quoted context omitted.

Even if he does it on Google's time, all his contributions are still licensed under GNU GPL V2 so Google cannot claim any ownership over Git.

The GPL is a license, not a Contributor Agreement or a Copyright Transfer. The author remains the owner of the copyright when they let others use it under a license, even open source licenses like the GPL. Licensing a software out does not mean the author can no longer "claim any ownership". In the case of OSS licenses, it just means that they can't claim sole ownership.

Yes, but from the perspective of the end user (me), the license guarantees that I can use the current version of the software for free forever without Google or anyone else forcing any changes.

Plus, if I don't like any changes they make, I can fork my own copy and continue developing on that (which the community will certainly do in a heartbeat if needed).

Re: Introducing Git protocol version 2

#129

Post by arvinds »

icebraining wrote: post #42
cesarb wrote: post #41

Earlier quoted context omitted.

> if you ever design a protocol or file format to communicate between machines always remember to add a version field or some other way to allow for updates and revisions later without breaking everything Also, somehow make sure no servers, clients, or third-party middleboxes break when the version field is incremented. The TLS protocol designers had to give up on the version field; it's now going to forever be stuck…

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.

Amen!

Re: Introducing Git protocol version 2

#130

Post by newscracker »

Sometime in the far future, someone will write an interesting story about how a double null byte came into existence in the git request protocol, and it will be amusing and interesting to look back. As the saying goes, hindsight is always 20/20. I'm glad that they found ways to maintain backward compatibility, at only a minor cost to understanding things.
Post reply on HN