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

101–110 of 167 posts

Re: Introducing Git protocol version 2

#101

Post by oripring »

bluejekyll wrote: post #61
simias wrote: post #28

Let that be a reminder to all the coders out there: 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. Having a way to specify extensions in a backward-compatible way is nice too.

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 message header hasn't been fully exhausted yet. Beyond the spare bit[1] in the header there is unassigned OPCODE values which can be used to bend the format in new ways[2].

1] It was briefly used experimentally if I recall

2] https://tools.ietf.org/html/draft-ietf-dnsop-session-signal

Re: Introducing Git protocol version 2

#102

Post by simplicio »

fiatjaf wrote: post #89
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!"

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.

Both Git and Linux are trademarked, presumably to prevent such hijinx

Re: Introducing Git protocol version 2

#104

Post by biohax2015 »

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

Fun fact: if you google “git blame” it returns his wikipedia entry.

Re: Introducing Git protocol version 2

#105

Post by jburgess777 »

bluejekyll wrote: post #61
simias wrote: post #28

Let that be a reminder to all the coders out there: 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. Having a way to specify extensions in a backward-compatible way is nice too.

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...

Re: Introducing Git protocol version 2

#106

Post by abjorn »

AdmiralAsshat wrote: post #92
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.

Isn't it customary to at least rename the fork?

Customary, but unless the name is trademarked, not required.

Re: Introducing Git protocol version 2

#107

Post by skywhopper »

AdmiralAsshat wrote: post #76
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

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 reputation is so tarnished that my gut reaction is at odds with my rational one, and that's a sad thing to realize.

Re: Introducing Git protocol version 2

#108

Post by Bjartr »

rwmj wrote: post #60

Is there a git protocol variant that allows the client to avoid downloading objects that it already has stored locally in another repository or cache? For example: I have the Linux kernel already cloned in some directory. I clone a second repo which has the Linux kernel as a submodule. Can I clone the second repo straightforwardly without having to download Linux a second time? (Well yes, but only by manual intervent…

Maybe this project could work for you?

https://github.com/jonasmalacofilho/git-cache-http-server

Re: Introducing Git protocol version 2

#109

Post by lsiebert »

I'm a very (very) minor contributor to git.

If you are at all interested in hacking on Git, it's not that difficult. Knowing C and portable shell scripting for writing tests are the big things.

One sticking point, you need to submit patches to the mailing list, you can't just do a github pull request.

See https://github.com/git/git/blob/master/Documentation/Submitt...

I still see github pull requests rather frequently, even though they have never been allowed. All discussion AND patches go through the mailing list, much like the linux kernel.

Re: Introducing Git protocol version 2

#110

Post by cesarb »

CGamesPlay wrote: post #97
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…

What would break? Are you saying a TLS 1.3 client would not be able to connect to a TLS 1.2 server because the version request would cause the server to reject the client?

Yes. Or worse: a completely unrelated box in the middle of the path could drop all the TLS 1.3 packets, so instead of a clean rejection, the connection gets stuck.
Post reply on HN