►
From YouTube: Git LFS at Light Speed - Git Merge 2017
Description
Lars Schneider & Taylor Blau, of AutoDesk and GitHub respectively, discuss recent performance improvements to Git LFS.
Git and its extensions are becoming more popular than ever. However, certain use cases may still be suboptimal. We identified a way to dramatically improve performance in a popular Git extension - LFS (Large File Storage) - that required changes in both Git Core, and the extension itself. Based on our combined experiences we’ll walk you through the process of a successful contribution to each project with the help of mailing lists and Pull Requests. If you have already a bit of Git command line knowledge then this talk will prepare you for your first contribution to Git, an extension, or both.
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
Brendon
search
Brendon
said
my
name
is
Lars
and
over
the
last
couple
of
months
later
on
died,
we
met,
get
LFS
dramatically
faster.
That
was
an
easy
project
because
we
had
to
make
changes
in
good
core
and
in
the
good
LFS
extension
code
in
the
next
30
minutes,
or
so
we
will
talk
about
some
challenges
that
we
met
through
this
project.
A
But,
first
of
all,
let's
look
at
the
results
of
our
improvement
here
in
the
upper
terminal.
You
see
the
last
good
version,
2.2
10
and
in
a
lower
terminal
there
were
current
version
2.7
and
now
we
are
going
to
check
out
a
branch
with
500
files
in
LMS
we're
going
to
check
out
and,
as
you
can
see,
the
new
versions
already
start
is
already
done
when
the
old
version
hasn't
even
started.
Yet
so
that's
good
LMS
at
Lightspeed.
A
A
So,
first,
let's
look
at
a
repository
without
LMS
and,
let's
add
a
bunch
of
code,
one
megabyte
through
our
repository
and,
let's
also
add
our
large
video
file.
So
after
this
commit
our
repository
has
a
size
of
one
hundred
and
one
megabyte,
and
then
we
change
our
mind
and
we
change
the
color
of
this
video.
A
So
and
then
we
add
this
new
version
of
the
view
to
our
repository,
which
will
add
another
100
megabytes
to
our
repository
and
we
change
our
mind
again,
which
means
we
would
add
yet
another
hundred
megabytes
to
our
repository-
and
here
you
can
see
this
tiny
repository
with
just
one
large
file
and
only
three
commits
has
already
grown
to
a
size
of
301
megabyte.
Now
you
can
imagine
I
work
at
Autodesk
and
we
have
repositories
with
thousands
of
large
files
and
hundreds
of
developers.
So
you
can
imagine
the
repository
size
of
these
projects.
They
explode.
A
Okay.
So
now,
let's
look
at
the
very
same
situation,
but
with
get
LMS
enabled.
So
again
we
add
a
bunch
of
code
and
we
add
our
large
video
file,
but
instead
of
adding
the
video
file
directly
to
the
repository,
it
is
uploaded
to
a
large
file,
storage
server
and
only
a
pointer
is
placed
in
our
repository.
A
So
this
is
great
because
when
you
want
to
when
you
want
to
clone
this
repository,
you
just
have
to
transfer
one
megabyte
of
data
which
is
super
fast
and
if
you
check
out
the
master
branch,
then
get
and
get
it.
Fs
is
clever
enough
to
figure
out
what
large
files
need
to
be
transferred.
In
our
case
here
we
need
to
transfer
the
last
version
of
the
video,
the
red
version
and
then
get
LMS
will
download
it
on
the
checkout.
A
So
that
means
just
in
this
tiny
example:
we
already
saved
60%
of
the
bandwidth,
and
now
you
can
imagine
with
large
repository
with
thousands
of
large
files
and
hundreds
of
versions.
The
savings
are
incredibly
much
incredibly
greater
so,
and
this
is
really
what
l
FS
achieve,
but
let's
go
back
to
our
speed
improvement
contribution.
So
how
did
we
make
kids
LF
s
so
much
faster
in
order
to
understand
that
we
need
to
look
at
a
good
checkout
process.
A
So
this
is
our
git
checkout
process
and
when
ever
get
finds
a
pointer
file
during
the
checkout
process,
it
will
take
this
pointer
file
and
give
it
to
a
new
git
LFS
process.
The
guitars
process
will
go
up
and
download
the
file
if
necessary,
and
then
it
will
give
back
the
content
of
the
file
to
get
and
then
it
will
shut
down.
A
This
entire
process
is
called
the
git
clean,
smart
filter
mechanism,
and
this
process
will
be
will
happen,
what
happens
for
each
and
every
file
in
your
repository.
So
that
means,
if
you
have
a
thousand
L
of
s
files
in
your
repository,
then
this
filter
process
is
invoked
a
thousand
times
well.
Processing
location
is
expensive,
especially
on
Windows,
and
that's
why
this
takes
a
long
long
time.
A
A
Alright,
in
the
remainder
of
this
talk,
I
will
focus
on
the
good
contribution
process.
I
make
some
changes,
I
mean
I,
mean
I
implemented
the
protocol
in
gate.
That
was
interesting,
but
what
was
even
more
interesting
is
really
the
contribution
processing
it,
because
that
differs
a
little
bit
from
the
contribution
process
that
you
know
from
most
other
open-source
projects
and
afterwards
Taylor
will
talk
about
some
design
decisions
that
he
made
while
implementing
the
protocol
in
git
LFS
all
right.
So
now,
how
do
you
contribute
a
change
to
get
well?
A
A
If
you
can't
find
your
idea
well,
then
it's
time
to
write
an
RFC,
a
request
for
comment:
why
is
it
necessary?
Well
get
is
an
open
source
project,
so
that
means
you
can't
force
a
change
in
Turgut.
You
need
to
present
your
idea
and
you
need
to
convince
the
community
that
your
idea
is
a
good
idea
and
then
they
might
accept
it.
A
pretty
convincing
argument
in
the
gif
community
is
performance.
So
if
you
can
measure
performance-
and
you
can
show
your
idea
mags
get
such
answers
faster
than
do
it.
A
That's
good
after
you
send
URF
see
a
discussion
might
start
on
the
mailing
list
and
you
should
follow
a
couple
of
rules
to
play
along
nicely
with
the
good
folks.
So
one
rule,
is
they
really
like
inline
replies
or
bottom
replies?
Don't
make
top
postings
because
they
are
frowned
upon
and
also
configure
your
email
editor
to
send
text
only
emails,
HTML
emails
or
another
one
as
well.
A
Okay,
at
this
point,
you
have
discussed
your
idea
and
you
have
a
pretty
good
idea
about
the
things
that
you
want
to
do,
so
you
can
start
working
on
your
feature.
Usually,
when
you
implement
a
feature,
you
would
start
from
the
get
master
branch.
If
you
fix
an
existing
feature,
then
we'll
you
would
start
from
the
main
branch
and
then
you
implement
your
feature
and
the
good
guys
they
are
pretty
picky
about
their
coding
style.
So
you
want
to
read
the
coding
guidelines
and
write
your
code
with
these
in
mind,
but
that
don't
stop
there.
A
You
should
also
write
tests
for
your
feature
to
prove
that
it
works
as
expected.
And
last
but
not
least,
you
should
write
documentation
to
explain
how
your
feature
works
to
the
end-user,
and
then
you
commit
your
change,
but
when
you
write
your
commit
message,
then
please
be
aware
that
the
get
community
cares
deeply
about
commit
messages
for
them.
They
are
as
important
as
the
code
itself
and
a
good
commit
messages
has
a
number
of
properties.
So,
first
of
all,
it
has
a
short
one-line
description.
A
Second,
there
should
be
a
paragraph
that
explains
the
problem
that
you
want
to
solve
with
this
with
this
commit.
Third,
you
should
explain
your
solution
and
you
should
not
only
explain
your
solution.
You
should
also
explain
alternative
solutions
that
you've
considered
but
discard
it,
and
you
should
also
explain
why
you've
discarded
them
in
general.
A
commit
message
should
be
self-contained.
That
means
a
reader
shouldn't
need
any
external
resources
to
understand
the
content
of
your
commit
message,
and
last
but
not
least,
you
should
add
your
sign-off.
You
have
to
add
your
sign-off.
A
So
after
we
spent
all
these
commits
you're
not
done
yet
because
a
mailing
list
then
has
an
interesting
property.
So
whatever
you
send
to
this
mailing
list,
is
there
you
can't
change
it
after
effect
and
that's
right,
you
should
make
sure
that
your
commits
are
in
the
best
possible
state,
and
the
most
obvious
thing
to
do
is,
of
course
you
would
build
get
and
you
should
make
sure
get
build
clean
on
your
machine.
A
If
you
have
a
number
of
commits,
that's
call
to
get
serious,
then
you
should
also
make
sure
that
each
individual
individual
commits
will
clean,
and
you
can
do
that
with
the
get
rebase
commands
that
I've
shown
here
and
then,
of
course,
you
need
to
run
the
tests
and
make
sure
all
the
tests
pass.
As
a
matter
of
fact,
there
are
many
different
rules
that
you
could
follow
here.
Here's
another
one,
for
instance,
to
check
that
you
don't
have
trading
rights
places
with
the
get
distressed
check
them
out.
A
A
A
So
when
your
commits
are
in
the
perfect
state,
then
you
can
use
the
gift
from
a
pet
on
command
to
transform
your
commits
to
patch
files
and
these
pets.
Well,
they
they
look.
Interesting
and
I
want
to
go
through
their
structure
a
little
quick
here.
So
they
have
an
email
header.
Then
they
have
the
commit
message
that
you
have
written
in
your
commit.
Then
they
have
a
section
for
additional
explanations
that
you
can
use
for
your
own.
There's
a
section
for
the
statistics
about
your
change,
you'll,
actually
change
and
your
own
get
version.
A
And
if
you
use
my
prepare
pet
script
then
this
will
insert
some
additional
information.
For
instance,
it
will
insert
the
base
committed
that
you've
used
to
write
your
patches
and
it
will
insert
a
link
to
your
github
repository
hosting
your
patches
so
that
people
that
prefer
reviewing
stuff
on
github
can
do
that
easily
alright.
A
A
Reviewing
it
and
that's
great
and
I
review,
sometimes
means
that
someone
doesn't
agree
with
you
and
criticizes
your
code,
and
what
you
should
do
is
find
agreement
find
a
solution
that
works
for
them.
As
well
as
for
you
and
when
you
find
these
solutions,
then
make
notes
and
then
of
course
you
update
your
commits
with
these
solutions,
and
you
also
check
your
comments
as
thoroughly
as
I
explained
it
earlier.
And
then
you
prepare
the
next
round
of
your
pet
series,
and
here
the
notes
come
into
play.
What
I
usually
do
is
I.
A
Take
these
notes
to
write
a
high-level
description
of
the
changes
that
I
have
made
between
the
different
versions
and
that
helps
the
reviewers
to
see
what
you've
actually
worked
on
and
my
prepared
pet
script
actually
supports
this
kind
of
workflow.
So
you
can
add
a
number
with
the
version
of
your
pet
series
in
order
to
generate
the
right
emails
and
then
again
you
sent
the
patches
to
the
mailing
list
and
you
should
see
everyone
who
has
reviewed
your
patches
so
that
so
that
you
can
make
sure
that
they
get
they
get
the
updated
version.
A
So
to
recap
that
really
quick,
let's
look
at
the
entire
contribution
cycle,
you
start
with
an
RFC
and
then
you
send
the
first
version
of
your
patches.
Hopefully
you
get
reviews
and
based
on
the
reviews,
you
create
a
version
two
of
your
pet
series
and
then
you
get
other
reviews
and
then
you
create
yet
another
version
and
so
on
and
so
on.
Sometimes
it
takes
up
to
eleven
versions
to
get
accepted,
and
when
your
change
is
accepted,
then
it
will
be
merged
to
next
branch.
A
It
will
sit
on
the
next
bunch
for
a
while,
so
that
to
make
sure
you
don't
break
it
and
then
really
merge
to
the
master
branch
and
when
it's
much
on
the
master
branch.
Well,
that's
great,
because
that
means
it
will
be
released
to
the
next
major
version
of
get
that's
kind
of
the
gist
of
it.
You
can
learn
more
about
the
entire
contribution
process
in
the
documentation
section
of
the
given
its
repository
file.
A
Submitting
patches
is
the
one
you
want
to
read
there,
okay
to
wrap
that
up,
so
the
filter
protocol
change
that
I
made
to
get
on
here
are
a
few
statistics
about
it.
So
I
changed
1608
lines,
yet
it
took
11
iterations
to
get
accepted.
It
took
380
our
review
emails
that
went
back
and
forth
and
it
took
six
months
of
work.
A
B
Hi,
as
Lars
mentioned,
my
name
is
Taylor
I'm,
an
infrastructure
engineer
at
github,
where
I
work
on
get
LMS
and
for
my
portion
of
the
presentation.
I
wanted
to
speak
a
little
bit
about
some
of
the
changes
we've
made
in
recent
months
to
accommodate
and
support
the
feature
that
Lars
introduced
into
upstream
get
about.
But
before
we
dive
in
I
want
to
sort
of
illustrate
a
little
bit
of
the
timeline
of
things
that
have
gone
on
so
far
so
towards
the
end
of
October
of
last
year.
B
Junio
merged
Lars
is
filter
process
branch
into
the
next
branch
of
git,
and
we
know
that
towards
the
end
of
November,
get
2.11
is
scheduled
to
be
released.
So
this
just
gives
us
a
tell
FS
over
one
month
or
so
to
implement
support
for
the
new
process
filter
before
2.11
is
released,
and
our
main
objective
is
to
release
a
new
version
with
the
support
before
2.11,
so
that
users
can
upgrade
LFS
as
they
please
and
as
soon
as
they
update
dates,
get
the
time
that
it
takes
to
check
out.
B
A
branch
will
decrease
without
any
sort
of
additional
configuration.
So
now
that
we
have
a
time
frame
sort
of
centered
around
what
we
need
to
build,
an
LFS
I
want
to
take
a
quick
look
at
the
actual
feature,
we're
hoping
to
provide
to
users.
We
want
a
user
to
be
able
to
check
out
a
branch
and
then
beyond
that
branch,
but
under
the
hood
there's
a
lot
more
going
on.
B
If
you
rerun
this
command
with
the
trace
packet
flag,
you
can
see
that
first
get
sends
us
a
bunch
of
data
and
then
LFS
needs
to
respond
with
a
corresponding
set
of
data
before
they'll
actually
be
on
the
branch.
So
to
get
this
going,
Lars
kick
things
off
with
a
work
in
progress,
kind
of
spike
pull
request,
and
there
are
a
few
important
attributes
that
I
think
made
this
pleura
quest
particularly
successful
as
a
starting
point
in
building
this
new
feature
from
scratch.
B
The
first
is
that
it
was
published
as
a
work-in-progress,
the
code
that
was
provided
of
course
worked,
but
there
was
still
some
kind
of
open
questions
that
needed
to
be
answered
about
exactly
how
the
code
should
be
implemented
and
what
those
interfaces
should
look
like.
This
is
a
particularly
good
approach
to
getting
started
off
with
working
with
pull
requests,
since
it
affords
us
the
opportunity
to
get
something
working
without
getting
caught
up
in
the
implementation
details
upfront.
B
The
second
detail
is
that
large
stated
that
he
was
open
to
a
thorough
review
of
his
code
lars
ism
to
go
expert.
Nor
am
I
a
C
expert,
so
we
leverage
our
respective
areas
of
expertise
to
allow
us
to
work
quickly
in
the
areas
that
we
knew
best
while
making
the
other
part
other
parts
of
the
project
that
were
less
familiar
to
deal
with,
and
the
third
is
that
the
pull
request
was
relatively
small
in
size.
B
This
allowed
Lars
to
pretty
quickly
validate
that
the
idea
would
actually
work
within
get
LFS
and
we
could
get
to
discussing
the
remaining
implementation
questions
with
a
rough
sketch
of
everything
already
in
place
instead
of
working
through
those
questions
up
at
the
start.
So
to
recap:
when
starting
out
a
new
future
from
scratch,
start
small,
this
will
afford
you
a
few
key
benefits
when
making
the
rest
of
the
feature.
B
First,
by
not
worrying
about
the
implementation
upfront
you're
able
to
answer
a
very
important
question,
whether
or
not
that
feature
is
actually
going
to
work
by
validating
the
feature
that
it'll
actually
work,
you
find
a
Sessa
tienta
dit.
Add
the
implementation,
may
not
be
perfect,
but
it's
there.
So,
instead
of
worrying
about
it
upfront,
you
can
come
back
to
it
as
you
please
and
refine
it
along
the
way
and
that's
exactly
what
we
did
when
taking
larger
spike
branch
to
a
release.
B
If
I
identified
sort
of
five
key
steps
that
we
need
to
take,
and
then
we
implemented
each
of
those
as
a
pull
request
merging
back
into
his
until
we
were
eventually
ready
to
cut
this
as
a
release.
The
first
step
of
things
that
we
needed
to
do
was
create
a
series
of
integration
tests
to
verify
the
most
basic
behavior
and
this
change
sort
of
came
in
two
parts.
B
One
was
explicit
and
the
other
much
more
implicit,
the
explicit
test
was
small,
create
a
repository
with
all
SS
enabled
have
two
branches
with
one
file
on
each
branch
switch
between
the
two
branches
and
make
sure
that
the
files
were
there
and
had
the
correct
content.
The
implicit
change,
however,
was
much
larger
is
that
we
ran
the
entire
process.
The
entire
integration
suite
through
the
new
process
filter
to
verify
that
all
of
our
existing
features
and
assumptions
wouldn't
break
with
these
new
changes.
B
Once
that
was
done,
we
could
get
to
refining
the
packet
line,
implementation
that
Lars
provided
in
his
original
pull
request.
Now
for
those
unaware
packet
line,
is
an
encoding
format
that
get
uses
to
send
data
between
itself,
as
well
as
your
external
processes
like
get
LFS
Lars
provided
an
additional
and
initial
implementation
of
this
protocol
and
go,
but
there
were
a
few
things
that
I
wanted
to
go
in
and
refine
before.
We
could
use
the
code
elsewhere.
B
This
was
the
pull
request
that
did
that,
and
it
was
fairly
uninteresting
some
light,
refactoring
some
easier
testing
and
it
made
the
following
steps:
kind
of
much
more
fluid.
So
once
we
had
a
solid
base
to
start
with
at
the
kind
of
most
basic
level
of
packets,
we
could
start
implementing
higher
level
ap
is
that
would
be
able
to
understand
and
answer
some
of
the
questions
that
get
would
ask
us
in
the
process
filter
communication
now
to
implement
this.
We
chose
the
scanner
pattern
which
is
common
in
many
languages,
but
particularly
and
go.
B
This
worked
great
for
our
use
case.
The
scanner
allows
us
to
consume
data
in
a
sequential
loop
which
matches
perfectly
the
way
that
get
sends
data
from
itself
to
LFS.
So
here's
a
little
bit
of
an
example
of
how
it
works
in
a
loop.
We
call
the
scan
method,
which
returns
true
when
there's
more
data
to
process
or
false
when
there's
an
error
or
where
at
the
end
of
the
stream.
B
So
while
we
have
data
to
process,
we
grab
the
next
request
that
gets
sent
to
us
decide
based
on
the
command
that
get
told
us
to
do
what
we
should
actually
do,
whether
that's
cleaning,
smudging
or
doing
something
that
we
don't
know
about,
and
then
once
we're
done,
clean
up
any
errors
and
respond
as
appropriate
and
really
at
the
highest
level.
That's
about
it!
B
That's
all
that's
needed
to
kind
of
make
the
most
basic
decisions
about
what
we
should
do
according
to
what
gets
said,
but
there's
a
problem
with
this
implementation
is
that
the
header
type
that
we
were
returning
back
included
this
payload
field,
specifically
what's
wrong
with
the
payload
field.
Is
that
you'll
notice
it's
a
byte
array
or
a
slice
of
bytes?
Now
this
is
fine
when
we're
converting
from
pointer
files
to
large
objects,
because
the
data
of
the
pointer
files
is
relatively
small
and
can
be
sent
and
stored
in
memory.
B
A
buffered
upfront,
however,
for
converting
the
other
way
around
for
large
files
down
to
pointers.
These
files
often
exceed
the
available
memory
on
your
computer,
so
they
can't
be
buffered
all
up
once
at
front.
So
what
we
need
is
sort
of
a
way
to
deal
with
this
chunk
data
that
get
is
sending
us
in
a
stream
like
fashion,
so
that
kind
of
kicked
off
the
next
and
remaining
two
series
of
PRS.
B
That
was
a
packet
line
based
I,
oh,
so
the
first
thing
that
we
did
was
we
provided
an
I/o
reader
in
now
for
those
that
are
unaware,
the
I/o
reader
interface
and
go,
which
is
a
part
of
the
standard
library,
looks
like
this.
It
has
one
method
called
read
which
takes
in
a
byte
buffer
P,
which
you
can
read
from
an
underlying
data
source
into
and
it
returns
and
the
number
of
bytes,
but
it
read
as
well
as
any
error
that
it
might
have
encountered
along
the
way.
B
Now,
if
you
remember
from
a
previous
pull
request,
we
have
this
great
interface
for
reading
packets
from
get
so,
we
can
combine
those
two
and
define
a
packet
line
based
reader,
that
we
can
consume
data
in
a
dreamlike
format,
that's
backed
by
this
underlying
protocol
from
gif.
So
we
create
this
type
and
implement
the
interface
by
defining
the
read
method,
as
shown
before
and
in
a
loop,
we
grab
the
next
packet
that
was
sent
to
us
from
get
returning
any
errors.
B
There
was
one
copy
that
packets
data
into
the
buffer
that
we're
reading
and
then
at
the
end,
returned
the
number
of
bytes
that
we
read
now,
of
course,
there's
some
more
detail
that
I'm
omitting
here
like
how
to
deal
with
over
filling
and
under
filling
these
buffers.
But
this
is
the
general
kind
of
sense
of
it
and
by
implementing
this
type,
it
allows
us
to
treat
this
chunk
data
stream
as
coming
from
get
in
the
same
way
that
you
would
treat
a
continuous
stream
of
data.
B
This
removes
the
constraint
that
we
have
to
read
all
of
the
data
for
a
particular
file
up
front,
but
it
also
provides
us
with
some
additional
benefits.
One
of
the
things
that
you
can
imagine
that
LFS
might
need
to
do
is
calculate
the
sha-256.
The
signature
of
the
contents
that's
being
sent
into
it
for
these
large
files,
so
we
can
use
the
scanner
pattern
from
before
grabbing
the
request.
B
B
Instead
of
reading
into
P,
you
read
out
of
P
and
into
the
underlying
data
stream
returning
m
the
number
of
bytes
that
you
wrote
and
any
error,
if
you
encountered
one
and
again,
this
is
an
interface,
you
can
write
to
many
things
like
files
or
network
sockets
or
in
our
case
get
so.
We
define
the
packet
line
writer
type
and
implement
the
I/o
writer
interface
by
defining
the
right
method.
B
We
keep
track
of
the
number
of
bytes
that
we've
written
so
far,
and
so
long
as
that
is
less
than
the
total
number
of
bytes
in
in
the
payload
that
we
wanted
to
write.
We
grab
the
biggest
amount
of
data
that
we
can
write
without
exceeding
the
maximum
length
of
a
packet
write
that
packet
returning
any
error.
B
If
we
encountered
one
increment,
the
number
of
bytes
that
we
wrote
and
then
at
the
end
return
that
and
again,
there's
of
course,
some
simplifications
that
I'm
making
here
like
one
of
the
attributes
of
this
protocol
is
that
you
should
write
the
biggest
packet
that
you
can.
So
we
have
to
accumulate
data
and
buffer
it
internally
up
to
the
maximum
packet
size.
Before
writing
it
out,
but
again,
this
is
the
basic
gist
of
it
and
like
the
reader,
it
provides
us
with
some
additional
benefits.
B
One
of
the
functions
you
can
imagine
LFS
implementing,
is
a
smudge
operation,
given
the
OID
or
sha-256
of
a
files
contents
and
a
destination
to
write
that
large
file
to
write
the
large
file.
So,
given
the
OID
and
the
IO
writer,
which
is
going
to
be
in
our
case,
backed
by
the
get
packet
line
protocol,
we
can
grab
the
local
path
on
disk,
where
the
cache
of
our
object
remains.
When
that's
in
your
dot
git
directory,
we
can
open
the
file
at
that
path
to
get
a
reading
handle
on
that
file.
B
Returning
any
error,
if
we
encountered
one
and
then
transparently
copy
from
the
file
down
into
the
packet
line
protocol
and
again
we're
sort
of
moving
through
a
few
layers
of
strata
here,
we're
going
from
the
packet
line
protocol
to
the
raw
bytes
and
then
down
into
the
file
system.
Again,
all
in
one
line
and
without
having
to
worry
about
it
and
really
that's
about
it.
B
Now.
This,
of
course
varies
on
a
few
different
attributes
of
your
repository
like
how
many
files
you
have
on
the
average
size
of
them,
but
in
general
about
80
times
faster
and
that's
fantastic,
going
forward.
We're
still
looking
at
a
number
of
ways
to
continue
improving
upon
these
changes
that
we've
made
and
get
and
get
LFS.
One
thing
that
we'd
like
to
do
is
instead
of
responding
with
the
entire
contents
of
a
phial
respond.
Instead
with
a
promise.
B
Now
it
gets
checkouts
our
fast
right
now
when
we
have
the
data
already
in
the
cache,
because
we
can
just
copy
it
and
stream
it
right
back
out
to
get,
but
the
problem
comes
when
you're
doing
say
a
clone
or
a
fetch
and
we're
downloading
lots
of
new
files
from
the
remote.
The
problem
here
is
that
if
we
don't
have
the
file
cache,
we
have
to
download
it
completely,
send
that
data
out
to
get
and
then
have
get
acknowledge
us
before
we
can
even
know
about
the
next
file.
B
B
One
other
thing
that
we'd
like
to
explore
is
instead
of
chunking
and
streaming
these
data,
these
payloads
through
the
pipe
exchanging
temporary
pads
on
disk,
and
we
know
that
in
pipes
on
UNIX
and
OSX
are
fast,
but
on
Windows
the
abstraction
makes
it
much
slower.
So,
while
the
improvement
in
checkout
speed
on
mac
was
about
80
times
on
Windows,
it's
only
about
57
to
65,
so
we're
exploring
whether
or
not
sending
just
files
instead
of
this
data
over
a
pipe
might
be
a
little
bit
faster
and
beyond
that
we
don't
know.
B
This
is
just
the
start
of
this
feature
and
we're
still
continually
discussing
ways
that
we
can
profile
and
figure
out
how
to
make
this
even
faster
in
the
future.
Taking
a
step
back
working
with
Lars
on
this
feature
was
such
a
pleasure.
We
were
able
to
work
across
two
different
organizations
between
Autodesk
and
github
to
impact
both
projects
LFS
and
git,
and
leverage
our
kind
of
relative
areas
of
expertise
to
make
a
contribution
that
will
impact
developers
using
both
projects
and
I.
B
Think
that's
why
I
get
and
source
control
and
sites
like
github
and
get
lab
at
bitbucket
are
so
important
is
that
they
facilitate
these
types
of
interactions
and
I
can't
wait
to
continue
to
make
this
improvement
and
I'm
so
excited
that
I
get
to
be
here
with
you,
where
you
make
these
types
of
improvements
every
day.
So
with
that,
thank
you
very
much.