►
Description
Presented by Brandon Williams, Software Engineer, Facebook
"Git continues to evolve. This talk will examine recent changes to the Git protocol focusing on the introduction of protocol v2 to reduce communication overhead and increase extensibility. We will do a deep dive into the challenges of changing the way Git works, while maintaining all-important backwards compatibility."
About GitMerge
Git Merge is the pre-eminent Git-focused conference: a full-day offering technical content and user case studies, plus a day of workshops for Git users of all levels. Git Merge is dedicated to amplifying new voices in the Git community and to showcasing the most thought-provoking projects from contributors, maintainers and community managers around the world. Find out more at git-merge.com
A
Thanks
for
having
me,
I
am
Brandon
Williams
and
it
has
been
roughly
nine
months
since
we
announced
git
protocol
v2
on
Google's,
open
source
blog
I'm
gonna
give
a
quick
deep
dive
into
what
we
did
to
accomplish
this
and
what
it
means
for
future
changes
to
the
gits
wire
protocol,
but
first
some
background
when
I
say
git
protocol
or
wire
protocol
I'm,
referring
to
the
network
protocol
that
is
used
to
fetch
from
or
push
to
remote
repositories.
Git
has
built-in
support
for
three
different
transports.
A
The
anonymous
git
protocol,
SSH
and
HTTP
all
of
its
wire
protocol
is
framed
in
as
in
terms
of
a
sequence
of
packet
lines
where
a
packet
line
is
a
four
byte
length,
followed
by
eight
some
payload
to
start.
Let's
take
a
brief
look
at
the
original
wire
protocol
and
see
what
motivated
us
to
find
a
reason
to
transition
to
a
new
protocol.
A
A
ref
advertisement
is
a
listing
of
all
the
branches
and
tags
that
are
stored
on
the
remote.
Each
ref
is
sent
in
its
own
packet
line
and
includes
the
rest
hash,
followed
by
the
refs
name.
The
very
first
reference
that
sent
is
a
little
bit
special
and
that
it
has
some
hit
information
hidden
behind
a
null
byte.
A
These
are
capabilities
or
extensions
that
have
been
added
to
the
protocol
over
the
years
and
they're
hidden
behind
a
null
byte,
because
in
C
strings
are
null
terminated,
which
means
that
old
git
clients
will
happily
ignore
any
information
past
a
null
byte,
but
newer
servers
will
know
to
look
for
it.
So
then,
the
client
that
uses
this
advertisement
as
a
menu
to
pick
which
convinced
commits
it
wants
to
fetch
from
so,
even
though
we're
only
interested
in
the
master
branch,
you
notice
that
the
server
sends
us
everything.
A
So
some
of
the
hurdles
with
doing
this
is
that
there's
a
single
hard
requirement
that
we
have
to
remain
backward
compatible,
meaning
that
new
clients
and
old
servers
and
old
clients
and
new
servers
should
remain
able
to
interoperate
without
failure.
So
we
needed
to
find
a
way
to
send
a
little
bit
of
extra
information
along
with
that
first
initial
request
that
would
be
ignored
by
older
servers,
but
newer
servers
would
know
to
look
for
it.
The
other
requirement
is
this:
bit
of
information
needs
to
be
sent
in
all
three
of
gets
built
in
transports.
A
Thankfully,
for
two
of
the
three
it's
pretty
easy
for
HTTP,
we
can
simply
send
an
additional
header
in
SSH.
You
can
set
a
environment
variable,
but
for
the
anonymous
get
transport
it's
a
little
bit
more
complicated
than
that.
A
request
using
the
anonymous
get
transport
looks
something
like
this.
It's
a
packet
line
that
includes
the
name
of
the
service,
your
you
are
requesting.
You
want
to
have
run
and
a
path
to
the
repository
and
then
back
in
2006.
There
was
support
for
more
parameters
that
were
added
that
were
hidden
behind
a
null
byte.
A
This
allowed
you
to
add
host
information.
Unfortunately,
when
this
was
implemented,
there
was
a
bug
that
was
introduced
which,
if,
as
you
can
see,
the
loop
control
variable,
that's
iterating
through
all
the
extra
parameters
is
only
ever
updated
if
the
extra
parameter
is
a
host
parameter.
So
if
you
included
anything
else,
the
server
would
end
up
spinning
in
an
infinite
loop,
which
you
don't
want.
A
The
bug
was
eventually
found
and
fixed
back
in
2009
in
the
following
way.
The
loop
was
changed
to
an
if
statement,
and
then
there
was
a
extra
check
made
at
the
end
to
disallow
any
request
that
included
parameters
other
than
a
host
parameter.
So
if
I
structure
to
request
like
I,
have
up
here
to
include
a
version
equal
to
parameter
as
an
extra
parameter
hidden
behind
a
null
by
it,
it
wouldn't
work
as
older
servers
who
either
end
up
in
an
infinite
loop
or
newer
servers,
would
flat-out
reject
this.
A
So
if
you
take
a
closer
look
at
the
bounds,
checking
that
they're
done
with
these.
If
statements
you'll
notice
that
it
only
checks
for
the
first
parameter,
which
isn't
an
empty
string,
so
by
placing
extra
versioning
information
behind
a
second
null
byte,
we
can
end
up
skirting
around
this
infinite
loop
bug
and
the
explicit
disallow
of
extra
arguments.
Besides
a
host
name.
So
an
only
newer
servers
know
to
check
for
information
behind
to
null
bytes
and
older
servers
will
happily
ignore
the
rest
of
the
extra
information
we
send
to
it.
A
So
now
that
we
have
a
mechanism
which
we
can
use
to
request
a
new
protocol
be
used,
we
can
take
a
look
at
what
the
structure
of
protocol
v2
is
so
by
default.
It
uses
the
original
wire
protocol,
and
so,
if
you
want
to
use
protocol
v2,
you
have
to
either
set
protocol
version
equal
to
in
your
git
config
or
you
can
pass
it
on
the
command
line
like
I've
done
here.
This
will
now
request
that
protocol
B
to
be
used,
regardless
of
the
transport
that
you're
using.
A
If
the
server
understands
that
an
additional
information
that
we
sent
it
then
we'll
see
a
different
response,
this
one,
which
is
a
capability
advertisement.
So
instead
of
listing
all
the
refs,
we
get
this
nice
listing,
which
includes
a
version
number
as
well
as
any
capabilities
or
commands
that
the
server
understands
or
it's
capable
of
performing.
A
The
client
can
then
use
this
capability
advertisement
to
select
a
command
that
it
understands
and
issue
a
follow-up
request,
so
for
trying
to
fetch
just
the
master
branch.
What
we
can
do
here
is
request
the
LS
refs
command,
which
will
give
us
a
listing
of
the
refs
on
the
remote,
but
we
have
added
an
additional
parameter
to
this
command,
which
is
a
ref
prefix.
This
allows
the
client
to
send
across
hints
to
the
server
about
the
branches
that
it's
interested.
In
specifically,
if
we
were
interested
in
the
master
branch,
we
would
send
refs
heads
master.
A
So
let's
take
a
look
at
what
this
translates
to
in
terms
of
performance
with
the
chromium
repository.
So
if
we
do
a
no
op
fetch
on
this
chromium
repository,
which
happens
to
just
be
a
fetch
where
you're
already
up
to
date
with
the
latest
master,
so
all
you're
doing
is
a
comparison
of
the
hash
of
the
master
branch
with
the
branch
that
you
have
locally
using.
A
So
to
recap:
we
now
have
a
mechanism
which
we
can
use
to
transition
protocol
versions.
So
if
we
need
to
upgrade
the
protocol
version
again
in
the
future,
we
can
do
that.
We
also
have
this
mechanism,
by
which
the
client
can
give
hints
to
the
server,
and
the
server
can
do
filtering
of
those
references
before
it
sends
them
to
us,
and
it
also
gives
us
a
little
bit
more
extensible
protocol
with
the
ability
to
add
further
commands
and
features,
some
of
which
we
can
do
some
examples
of
future
extensions.