1. 42
  1.  

  2. 25

    the initial request is rigid and does not include a field that could be used to request that new servers modify their response without breaking compatibility with existing servers

    we needed to find a side channel which existing servers would ignore but could be used to safely communicate with newer servers.

    Folks: Always put version numbers in your protocols and file formats. Oh, and while you’re add it, prefer extensible records too.

    1. 14

      In some IBM products I saw their smart design around C data structures and wire protocols: everything has in the first few bytes a static ascii “eyecatcher”, a version, a header offset, a payload offset, lengths, and usually a checksum. I’ve had arguments about this since but I believe the dozen byte trade off is worth it since within seconds you can identify the protocol and the payload, you know if you got the whole thing, you can detect (some) corruption, and if a future version of the structure is released the old one still works.

      1. 7

        This is done in their mainframe object code as well, specifically in the function prolog for XPLINK (and other linkage conventions, I believe). Every function is laid out with a header that starts with 0x00C300C500C500F1 (“CEE1” in EBCDIC, with null bytes) and some other bits of information that lets you walk the stack very easily. It also lets you get at the name of the function so not only can you walk the stack, but you can get the function name. This means you don’t need debugging information to get a stack trace. It’s also really useful is you are searching a raw hex dump.

        1. 1

          These were WebSphere MQ and DB2 LUW, which are strongly influenced by their mainframe heritage.

          I didn’t know about the linkage convention but assumed they must because on occasion I’d uploaded core dumps and they trivially walked them and someone mentioned once that they had an internal tool that did it. Their trace output was also top notch, really fantastic and clearly designed in from the start.

        2. 2

          Is that just a thing that IBM does with all their data structures? Company policy or something?

          1. 2

            No idea, but I wish it were externally explained and documented somewhere.

        3. 3

          I can entirely agree with you on that. The time it takes to implement a version number field is negligent compared to the amount of pain you’ll need to dedicate to supporting an old format with no version field.

        4. 15

          Tangential comment: I assume Google funded this in some way (either by paying a person to do it or offering money to the open source project). But, AFAIK, Git is not a Google project so I don’t really like that this introduction is coming from their blog as if it’s theirs. Maybe there is the official release somewhere else? Maybe I’m missing something and all this is kosher.

          1. 14

            Most of the Git core team is employed by Google to work on Git. The maintainer Junio Hamano is a Google employee whose job is to work on Git.

            That is why this announcement is happening on the Google blog.

            1. 8

              Git 2.18 is not yet released, so this is more of call for testing. Google-specific part here is that you can test against googlesource.com, because Google deployed v2 enabled server.

              1. 11

                It reads like an official announcement on behalf of the git project though, while not being on a git-related domain, which is what is somewhat surprising. Well, the first sentence does. The rest of the post wouldn’t have raised my eyebrow, but this part also confused me on first read regarding on whose behalf “we” is speaking here (Google? git? both?):

                Today we announce Git protocol version 2, a major update of Git’s wire protocol…

                1. 3

                  Google employs many git and mercurial developers. Very few organizations do source control on the scale of Google so it makes sense for them to fund developers of the tools they use.

                  1. 10

                    Myself, and I don’t think @mjn, are disagreeing that Google does a lot with source control and probably spends a lot of money on supporting git. My concern/issue is that git is not a Google project so it doesn’t quite feel right that, what feels like an official announcements should be on their website.

                    1. 3

                      A google employee wanted to share some open source work they’d been doing so they used a company blog. That doesn’t seem weird to me.

                      edit: I guess it’s worth adding that it wasn’t really announced in this blog post. You could have seen the discussions about this if you followed the git mailing lists.

                      1. 6

                        Google could have done a better job in this post explaining the relationship between Google, the author and the git project. One phrase would have made a ton of difference. For example, “I am John Foo, a Google employee and a member of the git core team” (with a link to some sort of proof on the git website)

                        1. 2

                          Well, there is such phrase, but at the end:

                          By Brandon Williams, Git-core Team

              2. 1

                Did you mean Git is not a google project?

                1. 1

                  Fixed, thanks.

              3. 6

                Two null bytes hack is truly loltastic.