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

31–40 of 167 posts

Re: Introducing Git protocol version 2

#31

Post by simias »

_wmd wrote: post #20
buckminster wrote: post #10

AIUI, the git ssh protocol is just the git protocol tunnelled through ssh. So why do they need different mechanisms for signalling V2?

Deploying Git over SSH entails locking the precise command line executable by the public key you use to authenticate. Locking SSH SendEnv down is mandatory too, otherwise thousands of people would have shell access to GitHub.com! This isn't even theoretical, there was an environment-related bug not 5 years ago involving Git. At least BitBucket was impacted, I think GitHub were patched before it was announced

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.

Re: Introducing Git protocol version 2

#32

Post by deathanatos »

xyzzyz wrote: post #24
buckminster wrote: post #10

AIUI, the git ssh protocol is just the git protocol tunnelled through ssh. So why do they need different mechanisms for signalling V2?

Because if you tunnel through ssh, you can signal v2 using ssh mechanism of setting environment variables. If you don't tunnel, you don't have this option. This is clearly described in the article.

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.

Re: Introducing Git protocol version 2

#33

Post by xenomachina »

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

> but because it is required

Just to confirm, but you meant "because it is not required", right?

Re: Introducing Git protocol version 2

#34

Post by Someone1234 »

xenomachina wrote: post #33
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

> but because it is required Just to confirm, but you meant "because it is not required", right?

Right. Edited.

Re: Introducing Git protocol version 2

#35

Post by kardianos »

seabrookmx wrote: post #4
ksec wrote: post #3

I thought google uses hg, have they switched over to git as well?

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

Re: Introducing Git protocol version 2

#36

Post by jordigh »

pjmlp wrote: post #6
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.

Go started on Mercurial and then eventually moved into Git.

And they like neither. They really want a versioned filesystem.

Re: Introducing Git protocol version 2

#37

Post by jordigh »

wereHamster wrote: post #17
needz wrote: post #8

Earlier quoted context omitted.

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

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.

Linus wasn't the only one with git; all Linux devs were in a hurry. This is also why Mercurial happened.

Re: Introducing Git protocol version 2

#38

Post by 49bc »

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

I wouldn't be so sure. They said one of the motivations was to "unblocking the path to more wire protocol improvements in the future".

Re: Introducing Git protocol version 2

#39

Post by icebraining »

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

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.

Re: Introducing Git protocol version 2

#40

Post by stevekemp »

ktsmith wrote: post #18
needz wrote: post #8

Earlier quoted context omitted.

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

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

Agreed.

Bitkeeper itself is open-source these days available via the Apache 2.0 License, but it is too little, too late:

http://www.bitkeeper.org/

Post reply on HN