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

91–100 of 167 posts

Re: Introducing Git protocol version 2

#91

Post by loeg »

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.

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

Re: Introducing Git protocol version 2

#92

Post by AdmiralAsshat »

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.

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

Re: Introducing Git protocol version 2

#93

Post by falsedan »

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…

git v2.0 came out 4 years ago; these release notes are regarding a new version of the wire protocol used to communicate with remote repos.

Re: Introducing Git protocol version 2

#94

Post by falsedan »

nothrabannosir wrote: post #78
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…

You could literally link the two object directories? I just tried this and it seems to work: git clone git://github.com/git/git mkdir git2 cd git2 git init cd .git/ rm -rf objects ln -s ../../git/.git cd ../ git remote add origin git://github.com/git/git git fetch # returned without downloading anything git checkout master ls # etc. If you seriously want to use this, you'll probably want to hard link the contents, in…

You can also use alternates:

  echo ../../../git/.git/objects >> git2/.git/objects/info/alternates
or use the original as a reference:

  git clone --reference git git://github.com/git/git git2
This sets up the alternates for you.

Re: Introducing Git protocol version 2

#95

Post by nneonneo »

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…

Per the TLS 1.3 RFC:

> In previous versions of TLS, this field was used for version negotiation and represented the highest version number supported by the client. Experience has shown that many servers do not properly implement version negotiation, leading to "version intolerance" in which the server rejects an otherwise acceptable ClientHello with a version number higher than it supports. In TLS 1.3, the client indicates its version preferences in the "supported_versions" extension (Section 4.2.1) and the legacy_version field MUST be set to 0x0303, which is the version number for TLS 1.2. (See Appendix D for details about backward compatibility.)

It's really too bad that the version field can't be used as a version field anymore, but thankfully the "extension" format is pretty flexible in that regard.

Re: Introducing Git protocol version 2

#96

Post by falsedan »

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.

Then don't waste peoples time with vacuous comments.

Re: Introducing Git protocol version 2

#97

Post by CGamesPlay »

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…

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?

Re: Introducing Git protocol version 2

#98

Post by gsnedders »

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.

Re: Introducing Git protocol version 2

#99

Post by pritambaral »

paxy wrote: post #86
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...

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.

Re: Introducing Git protocol version 2

#100

Post by EvilTerran »

stingraycharles wrote: post #50
sp332 wrote: post #48

Earlier quoted context omitted.

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?

If the newest version of a secure communication protocol includes some way to negotiate down to an older version, that opens the door to downgrade attacks - you risk ending up with a protocol that, in practice, has all the vulnerabilities of both versions.
Post reply on HN