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

161–167 of 167 posts

Re: Introducing Git protocol version 2

#161

Post by jkaplowitz »

joatmon-snoo wrote: post #157
jkaplowitz wrote: post #14

Earlier quoted context omitted.

Why LKML? Despite Git's origins from and use by the Linux project, it isn't especially tied to it now. LKML would presumably be the place for Linux to announce when they adopt this. The Google open source blog is among the several credible options for this post, since Google employs much of the core Git team, and this post discusses their experience deploying Git protocol v2 at Google. As noted in the blog text, it's…

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.

Okay, I guess that tie continues for historical reasons. At least people who don't otherwise subscribe to LKML can still receive Git release announcements via the second link.

I presume Git 2.18 (the first release supporting protocol v2) will be announced via both channels once it's out.

Re: Introducing Git protocol version 2

#162

Post by bronson »

Too wrote: post #134
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.

I'm mostly surprised they solved a critical server bug on the client side and by introducing even more hacks into the protocol. I mean, who in their right mind would run a public git server with this super easy to exploit DOS bug: Unfortunately due to a bug introduced in 2006 we aren't able to place any extra arguments (separated by NULs) other than the host because otherwise the parsing of those arguments would ente…

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.

Re: Introducing Git protocol version 2

#163

Post by harveynick »

falsedan wrote: post #139
harveynick wrote: post #119

Earlier quoted context omitted.

Ironic reply. Sincere apologies if you can't derive any information from my comment, but that doesn't mean there isn't any there.

The only information is “google employs me”.

Does Google use hg? “Yes and no. It’s complicated.” You can’t read anything into that?

Re: Introducing Git protocol version 2

#164

Post by harveynick »

ksec wrote: post #153
harveynick wrote: post #120

Earlier quoted context omitted.

The most recent reason public reference I can find to this is from 2016: https://cacm.acm.org/magazines/2016/7/204032-why-google-stor... Here's the money quote: "The team is also pursuing an experimental effort with Mercurial an open source DVCS similar to Git. The goal is to add scalability features to the Mercurial client so it can efficiently support a codebase the size of Google's. This would provide Google's dev…

Not sure why I got heavily downvotes. This above was the pieces of information that got me to think they were all on hg. So judging from the comment I stand corrected.

Your assumption was pretty reasonable based on the public information. Honestly I’d love to talk about how Google does source control/ code review etc. because it’s actually pretty interesting at this point. You know... for some values of interesting.

Re: Introducing Git protocol version 2

#165

Post by bluejekyll »

jburgess777 wrote: post #105
bluejekyll wrote: post #61

Earlier quoted context omitted.

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

This is a great resource. Thank you for sharing.

I don’t read that as DNS stoping to work, but more reasons why DNS is flaky in different scenarios.

Some of the issues there are things related to mitigation’s against reflection attacks etc. I haven’t read the entire doc, but does it go into concerns around DDOS and other such things, and how DNS servers to mitigate those attacks?

Edit: right in the intro. So a server needs to “understand” when it is under “attack” and only then put in mitigations against the attack. In the worst case, the server doesn’t do this, fixes the issues in this RFC to always respond and then amplify the attack.

Re: Introducing Git protocol version 2

#166

Post by rspeer »

icebraining wrote: post #147
rspeer wrote: post #133

Earlier quoted context omitted.

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

Git-annex doesn't look for files in random places. It uses the regular git remotes, plus something it calls "special remotes" which are basically accounts on file servers/S3/etc that you can manually add. If Github et all thought this was confusing, they could have made a "beginner's mode" that auto-selected the storage server based on the git server, like LFS does. Which would still have been better, since it wouldn…

> Right, but LFS can't be used in asymmetric cases at all - it assumes anyone with access to the git repository has access to the LFS storage area.

Wait, really? I thought that Git LFS let people with push access push files to the LFS area, which can then be read by anyone. That's asymmetric in the way everyone expects from GitHub. But I didn't use Git LFS because it's too expensive.

Yes, I probably encountered extra weirdness from git-annex, from the fact that the codebase was on GitHub, which doesn't support git-annex, so _everything_ in git-annex had to be on a different remote.

If it was meant to be used with the upstream as the only remote, that makes things make a lot of sense, and explains why my attempt to use it felt a lot like early Git, where there was no good upstream service like GitHub.

Re: Introducing Git protocol version 2

#167

Post by lsiebert »

ImJasonH wrote: post #155
pm215 wrote: post #151

Earlier quoted context omitted.

It's unfortunate that github doesn't let a project disable the on-website UI for pull request submission; as it is it's easy for somebody to end up wasting their time trying to submit a change that way. (QEMU has that issue too.)

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

And that's nice, but I'd also love to see a bot that formats the pull request into a patch email for you.
Post reply on HN