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

141–150 of 167 posts

Re: Introducing Git protocol version 2

#141

Post by pilif »

nneonneo wrote: post #95
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…

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

>but thankfully the "extension" format is pretty flexible in that regard

Just like the version field.

I'm sure middlebox software is being updated as we speak to terminate connections with unknown versions in the „supported_versions“ extension.

Re: Introducing Git protocol version 2

#142

Post by wereHamster »

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…

There's git command for that: https://git-scm.com/docs/git-worktree

Re: Introducing Git protocol version 2

#143

Post by wiz21c »

pritambaral wrote: post #99
paxy wrote: post #86

Earlier quoted context omitted.

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.

so right now, Google has a word to say about the direction of git.... But that's normal.

Re: Introducing Git protocol version 2

#144

Post by xorcist »

avar wrote: post #57

The specification of the v2 protocol is here: https://github.com/git/git/blob/master/Documentation/technic... One of the more exciting things is that it can now be extended to arbitrary new over-the-wire commands. So e.g. "git grep" could be made to execute over the network if that's more efficient in some cases. This will also allow for making things that now use side-transports part of the protocol itself if it mad…

If you are to link to a git repo, don't link to some unoffical mirror. That would just confuse search engines.

The specificiation of the v2 protocol is here: https://git.kernel.org/pub/scm/git/git.git/tree/Documentatio...

(There are a couple of repos listed as official mirrors, such as the googlesource.com one, but the one you linked to isn't one of them.)

Re: Introducing Git protocol version 2

#145

Post by Ceezy »

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

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

Re: Introducing Git protocol version 2

#146

Post by xorcist »

Someone1234 wrote: post #22

Too bad they didn't make Git LFS part of Version 2[0]. Most vendors[2] support LFS already but because it isn't required, some still lack it and its support cannot be assumed. [0] https://git-lfs.github.com/ [1] https://github.com/git-lfs/git-lfs/wiki/Implementations

What kind of changes to the wire protocol would help git-lfs? It seems to have no specific dependencies on protocol features.

If standard git ever implements shallow blob fetching, it would preferrably make git-lfs obsolete rather than help it.

Re: Introducing Git protocol version 2

#147

Post by icebraining »

rspeer wrote: post #133
icebraining wrote: post #39

Earlier quoted context omitted.

I say that's LFS' fault. Why do you even need a custom server? It should just be able to use any ol' file server or S3-API compatible service, and do everything on the client side. I find git-annex a much better solution, it's a shame everyone went with LFS.

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't have required a custom server API.

It was very hard to use in asymmetric cases where different people have different credentials

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.

Re: Introducing Git protocol version 2

#148

Post by fanf2 »

abjorn wrote: post #106
AdmiralAsshat wrote: post #92

Earlier quoted context omitted.

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

Customary, but unless the name is trademarked, not required.

Some licences require a change of name for substantial modifications, e.g. the Artistic Licence and Apache Licence v1. But those kinds of clauses are pretty rare nowadays.

Re: Introducing Git protocol version 2

#149

Post by tialaramex »

apple4ever wrote: post #81
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…

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

It's almost invariably end users who suffer, not the "makers". And because of a human cognitive bias it doesn't matter that the middleboxes are wrong, if you get a new Chrome and it doesn't work you blame Chrome, you don't blame the middlebox that had been getting this wrong for five years.

Almost a year's work on TLS 1.3 was spent on working around problems with middleboxes. Because without that it would be impossible to deploy in practice. TLS 1.2 took years to deploy because so many middleboxes were incompatible and we had to wait for them to rust out.

Re: Introducing Git protocol version 2

#150

Post by avar »

xorcist wrote: post #144
avar wrote: post #57

The specification of the v2 protocol is here: https://github.com/git/git/blob/master/Documentation/technic... One of the more exciting things is that it can now be extended to arbitrary new over-the-wire commands. So e.g. "git grep" could be made to execute over the network if that's more efficient in some cases. This will also allow for making things that now use side-transports part of the protocol itself if it mad…

If you are to link to a git repo, don't link to some unoffical mirror. That would just confuse search engines. The specificiation of the v2 protocol is here: https://git.kernel.org/pub/scm/git/git.git/tree/Documentatio... (There are a couple of repos listed as official mirrors, such as the googlesource.com one, but the one you linked to isn't one of them.)

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.

Post reply on HN