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

81–90 of 167 posts

Re: Introducing Git protocol version 2

#81

Post by apple4ever »

cesarb wrote: post #41
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.

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

In my opinion, they should break things that misuse the version field. Then maybe the makers will learn to develop properly.

Re: Introducing Git protocol version 2

#82

Post by jkaplowitz »

hartator wrote: post #73

Is Git a Google project now?

No, but many of the core contributors are employed by Google and spend time on it as part of their day job (with Google's knowledge and permission). This post straddles both the open source part of their jobs and the "Git deployment at Google" part.

Re: Introducing Git protocol version 2

#83

Post by brown9-2 »

castis wrote: post #75
trumped wrote: post #64

Earlier quoted context omitted.

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

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.

Re: Introducing Git protocol version 2

#86

Post by paxy »

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

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.

Re: Introducing Git protocol version 2

#87

Post by [deleted] »

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…

[deleted]

Re: Introducing Git protocol version 2

#88

Post by gchpaco »

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.

I damn near released a (private) message protocol without a version field a couple months ago, and I know better. Fortunately stopped myself and added it before any actual data got released.

Re: Introducing Git protocol version 2

#89

Post by fiatjaf »

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

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.

Re: Introducing Git protocol version 2

#90

Post by slrz »

Someone1234 wrote: post #65
_ikke_ wrote: post #62

Earlier quoted context omitted.

Git LFS is not part of core-git, but an extension built and maintained by github, and the code lives outside of the git tree, so it cannot be a required part of the protocol.

> Git LFS is not part of core-git I know, that's what I am suggesting should change in version 2.0. It is a widely supported popular extension that solves a major pain point for Git, most vendors have adopted it. New things can absolutely be required as part of a new protocol version, in fact this blog post lists several new things that will be new in 2.0 and beyond. The analogy I'd use is HTTP/2 and SPDY. SPDY start…

The way to make that happen is for some interested party to take the LFS code and submit it for merging into git proper. If there were prior attempts, study them carefully and learn from them. It probably won't be accepted the first time, so you need to be persistent, addressing reviewer's comments along the way.
Post reply on HN