Introducing Git protocol version 2 (opens in new tab)

I came across this email from Linus announcing the handover: https://lwn.net/Articles/145123/

It's interesting how the first ever git project itself was looking for new maintainer almost as soon as it was created.

wow! what an accolade

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.

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.

Same here. I was like, "If there are about to drop 3 versions at the same time like angular, I need to you use SVN ASAP".

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

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.

One of the places it's hosted at is https://kernel.googlesource.com/pub/scm/git/git

See the list of URLs at https://public-inbox.org/git/xmqqindt6g1r.fsf@gitster.mtv.co...

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.

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.

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

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?

It's been fixed for almost a decade. You're asking for a retroactive CVE?

You can read about their fix by clicking the next link in the article.

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

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

The repository I linked to is official. See https://public-inbox.org/git/xmqqindt6g1r.fsf@gitster.mtv.co...

What list are you referring to? If it doesn't list the one on GitHub it needs to be fixed.

My experience with git-annex is that it seems heavily designed for individuals and not for projects. The places it looks for files are often just a computer you were once developing on, and it sometimes expects you to go find that computer. It never forgets about any crazy place your files have been.

It was very hard to use in asymmetric cases where different people have different credentials, such as where one person has access to a computer and others don't, or where a couple of core developers have authenticated R/W access to a file server or an S3 bucket and everyone else just has HTTP.

They'd just stick to Protocol 1

> 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 started out as a Google produced extension to HTTP, gained popularity, and was then standardized/merged into the HTTP/2 standard. All I am suggesting is Git LFS receive the same treatment.

Right. Edited.

Totally agree! I made nopullrequests.com to help solve this.

Here is a more detailed analysis, which shows all contributors:

https://public.gitsense.com/insight/github?r=git/git#b%3Dgit...

These are contributions by Linus:

https://public.gitsense.com/insight/github?r=git/git#b%3Dgit...

and as you can see, his contributions, really tapered off after 2010, while contributions from Hamano remained steady from 2008 to present date, as shown below:

https://public.gitsense.com/insight/github?r=git/git#b%3Dgit....

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.

I don't think that answers the parent's question, if the update was in the git protocol itself (encapsulated in the SSH session) then you wouldn't have to change anything at the SSH level.

As you point out selectively allowing a new environment variable could open a can of worms for shared hosts like github if they mess up their implementation.

I think what the person you're replying to is asking is why not, in the case of ssh, use the signaling in the git protocol, since it will be there anyways. That is, if you don't tunnel, you must signal w/ the git protocol. If you do tunnel, why use a different mechanism, since the signal in the git protocol must be there?

I think that this is because the SSH protocol isn't just encapsulating the Git protocol directly (the initial assumption of ssh "just" encapsulating the git protocol is not fully correct), and one of the parts that differs is this particular part. (Since on the git protocol side, we need to select a "service":

> a single packet-line which includes the requested service (git-upload-pack for fetches and git-receive-pack for pushes)

which in SSH would be done not by transmitting that packet-line but by instructing SSH to run that particular executable.

> This is clearly described in the article.

It really isn't, IMO; if you don't have precise knowledge of the protocols involved, I don't think anything in the article particularly spells this out.

Yes, but once you've updated the git protocol, ssh support comes for free. Having one mechanism is simpler than having two. And as your sibling notes, setting env vars from ssh has disadvantages. So why bother?

In fact, developers are allowed to use whichever VCS tool they want on their local machine (or on the online coding in the cloud CitC environment). Some opt to use hg. The canonical repo is in piper though, so the hg commits or git commits get converted before they land.

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 servers that support it.

Go started on Mercurial and then eventually moved into Git.

At the time Linus was the sole author/contributor of git, and he needed a replacement for BitKeeper in a hurry. BitKeeper had been made unavailable for Linux kernel development because the proprietor of BitKeeper was really unhappy that Tridge had reverse engineered the protocol and created an open-source client[1] which could talk to the Bitkeeper server. Linus created the first version of git sufficient to do a kernel commit in ten days[2].

[1] https://sourceforge.net/projects/sourcepuller/

[2] https://www.linuxfoundation.org/blog/10-years-of-git-an-inte...

(As Tridge tells the story[3], he telnet'ed to the bk port and typed "help" so it wasn't that much of a reverse engineering effort. :-)

[3] https://lwn.net/Articles/132938/

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.

I thought Linus Torvalds was almost wholly responsible for the initial development of git? Even so, everything, especially software, is easier in hindsight....

Using BitKeeper as the SCM for the Linux kernel always seemed like a bad idea and when issues between the company and the community peaked git was created.

https://git-scm.com/book/en/v2/Getting-Started-A-Short-Histo...

s/they/he/. It was Linus himself who alone created git, within a few weeks (two or three). At first it was just a handful of shell scripts, but it was self-hosting pretty early on.

Junio posts on the list when there's a new release, e.g. https://public-inbox.org/git/xmqqwoxw6kkk.fsf@gitster-ct.c.g...

It seems that https://groups.google.com/forum/#!forum/git-packagers is the closest thing to a formal announcement list that there is.

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.