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

41–50 of 167 posts

Re: Introducing Git protocol version 2

#41

Post by cesarb »

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 at "TLS 1.2", since too much would break otherwise.

Re: Introducing Git protocol version 2

#42

Post by icebraining »

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…

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.

Re: Introducing Git protocol version 2

#43

Post by Confiks »

It's quite a comedy that this feature has not been implemented for at least 6 years, solely because the raw git:// protocol's parameter handling was severely broken, and feature detection by disconnecting and retrying [1] was ultimately deemed far too dirty.

[1] https://public-inbox.org/git/CAJo=hJtZ_8H6+kXPpZcRCbJi3LPuuF...

Re: Introducing Git protocol version 2

#44

Post by jimmy1 »

needz wrote: post #8
Ericson2314 wrote: post #5

This is disgusting. So little forsight in the past... At least the outcome of quite useful.

IIRC, they were in a serious time crunch when they drafted/made git. I can't remember the whole story...

And really, like other famous software that people love to heap shade w.r.t how awful it is focusing only on it's warts instead of the immense productivity realized as a result, git really does have some nice parts and it was the best option for a while. The fundamental concepts of git is really not that hard to understand -- it's fundamental architectural model is event sourcing, and it's fundamental data structure is a DAG. Those are pretty good choices.

I personally have stuck to kind of basic git usages (call it "Git: The Good Parts" if you will), and have never had the problems people claim to have with git. It just has always worked, and it has always been there for me.

Re: Introducing Git protocol version 2

#45

Post by seabrookmx »

kardianos wrote: post #35
seabrookmx wrote: post #4

Earlier quoted context omitted.

For all the "big" Google projects they use a proprietary system called piper. I think all their open-source stuff (Angular, GoLang, Android) uses git (and sometimes Gerrit). Although given Google's scale, I'm sure there's some teams/projects that use Mercurial.

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…

> Gerrit is a review server that uses git

Yup! I use Gerrit at my company and share Administration duties with our Devops team.

I know Android uses Gerrit I just wasn't sure if Angular and co. did which is why I worded it a bit more vaguely.

Re: Introducing Git protocol version 2

#46

Post by Cynddl »

Retroity wrote: post #19
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

Non-Mobile link for those on desktop: https://en.wikipedia.org/wiki/Junio_Hamano

The mobile version of Wikipedia works perfectly fine in a browser. I personally prefer it for readability.

Re: Introducing Git protocol version 2

#47

Post by stingraycharles »

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.

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?

Re: Introducing Git protocol version 2

#48

Post by sp332 »

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?

Because it's up to the client to request HTTP 2 if they support it. https://http2.github.io/http2-spec/#discover-http

Re: Introducing Git protocol version 2

#49

Post by geofft »

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?

Clients can fall back, and falling back to HTTP/1.1 isn't a security problem the way falling back to, say, TLSv1.1 is.

Re: Introducing Git protocol version 2

#50

Post by stingraycharles »

sp332 wrote: post #48
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?

Because it's up to the client to request HTTP 2 if they support it. https://http2.github.io/http2-spec/#discover-http

But why is this not supported by TLS? Is it set up in such a way that it could never be amended to have a fallback?
Post reply on HN