►
Description
Presented by John Briggs, Engineering Manager, Microsoft
John is the engineering manager for the Git ecosystem team in Azure DevOps. His team is tasked with helping Git scale to support some of the largest repositories in the world with contributions to core Git, Git for Windows, and VFS for Git. Previously, John worked on the version control web experiences for Azure Repos and facial animation middleware for the games industry.
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
A
Most
of
you
will
know
that
as
gvfs
we
renamed
it
to
VFS
forget
also,
if
I
say,
vs
TS
I'm.
Sorry,
that's
a
very
ingrained
habit.
It's
as
your
DevOps
now
I'm
working
on
it.
We
also
contribute
to
core
get,
but
one
of
my
team's
primary
responsibilities
is
making
sure
these
big
get
mono
repos
inside
of
Microsoft
are
successful
and
the
biggest
among
them
is
Windows.
A
So
in
early
2017
we
moved
Windows
on
to
get
and
the
technology
we
used
to
do
that
was
VFS
forget
and
what
VFS
forget
allowed
us
to
do
is
really
kind
of
eliminate
the
working
directory
as
a
scale
vector
in
git,
which
was
one
of
the
big
blockers.
If
you
remember,
Syed
in
2017
talked
a
little
bit
about
five-minute
status
times
inside
of
the
repository
but
being
on
top
of
EFS
forget
really
really
eliminated.
That,
but
get
is
not
just
a
a
big
repository
in
terms
of
the
working
directory.
A
It
is,
but
it's
also
a
repository
whose
history
is
growing.
Very
very
fast.
Automation
was
creating
a
good
amount
of
that
commit
history.
This
is
the
windows
repository
as
of
January.
It
has
3.1
million
commits
and
24
million
almost
25
million
trees,
and
you
see
kind
of
where,
where
VFS
per
gate
take
silver
there's
just
one
branch
visible
to
the
client
and
in
a
clone
where
you
haven't
started
working.
A
Yet
there
are
no
objects
present,
but
the
presence
of
so
much
commit
history,
and
so
many
trees
was
really
a
scale
vector
that
we
hadn't
planned
for
in
the
initial
implementation,
because
we
made
the
decision
early
on
and
ef-s
forget
that
we
weren't
going
to
try
to
virtualize
commits
and
trees.
We
assumed
they
were
small
enough.
We
assumed
that.
A
Those
tree
misses
here's
how
the
repository
has
grown
since
its
inception,
and
you
can
see
that
it
has
been
just
steadily
accelerating
for
the
better
part
of
all
of
2017
and
the
first
half
of
2018
and
as
it
did
the
repository
performance
degraded,
and
that
was
one
of
the
big
things
that
we
had
to
go
fix.
We
we
had
moved
on
to
the
technology.
We
had
moved
windows
on
to
get,
but
we
hadn't
yet
finished
that
cultural
change
of
being
on
git.
It
means
different
things.
A
A
Of
those
commits
31,000
were
build
machines,
doing
build
machine
things,
checking
in
little
version
changes
across
the
repository.
Another
25,000
were
various
piece
of
automation
that
we're
running
through
the
PR
ap
is
creating
more
commits.
21,000
were
what
I
would
call
developers
at
their
workstations.
Doing
their
jobs,
those
are
the
important
ones.
Those
are
the
ones
we
really
want
to
enable
people
to
be
successful
with
and
another
15,000
were
code
movement
up
and
down.
The
tree.
A
The
the
parents
of
a
commits,
the
generation
number
of
the
commit
and
stoli
talked
to
last
year,
I
get
merged
about
how
how
much
of
a
difference
it
makes
in
the
time
we
spend
parsing
commits.
So
if
you're
interested
there
I'd
encourage
you
to
walk
it
watch
his
talk
from
2018,
but
this
last
year
we
taught
the
commit
draft
a
new
trick
and
it
is
storing
generation
numbers.
What
that
lets
us
do
with
the
commit
graph
is
answer
questions
about
the
topology
things
like
git
log
one-line
so
prior
to
the
commit
graph.
A
So
if
we
disabled
entirely
a
log
one
line
inside
the
OS
repository
will
return
in
about
40
seconds,
which
is
not
a
good
experience
for
anyone,
and
this
is
actually
the
best
run.
I
got
the
first
one
took
90
seconds
as
it
warmed
up
the
disk
cache
with
the
commit
graph
we're
now
returning
those
results
in
under
a
third
of
a
second.
A
So
this
is
a
huge
change,
a
huge
positive
benefit
for
the
developers
working
inside
the
repository.
Now,
of
course,
you
can
say
well
sure,
but
the
Windows
is
a
almost
pathological
case.
This
has
helped
other
repositories
and
sure
enough.
It
does
in
terms
of
the
Linux
repository
without
using
the
commit
graph.
We
get
the
same
log
one-line
performance
of
about
8
seconds
and
when
we
enable
the
commit
graph
it'll
return.
A
History
in
under
a
tenth
of
a
second,
so
this
is
something
we're
really
excited
to
be
able
to
do
inside
of
core
get
and
share
with
the
community.
This
is
available
in
get
to
Tony
on
I'd,
encourage
you
to
try
it
out
on
your
own
repositories,
it's
not
on
by
default.
Yet
so
you
can
go
in
with
git
config
core
not
commit
graft.
A
True
and
git
config
GC
dot
write
commit
graph
that
will
automatically
write
the
commit
graph
during
GC
and
if
you
want
to
go
ahead
and
start
getting,
the
benefits
just
call
git
commit
graph
right
and
so
I
encourage
you
to
try
it
out.
Let
us
know
how
it
works
for
you
and
I'm
just
happy
to
have
that
available
for
everyone.
A
So
we
got
to
a
good
spot
with
a
graph,
but
you
know
don't
forget
that
these
automation
were
generating
trees
at
a
rate
of
almost
8
to
1
for
every
commit.
We
were
generating
8
more
trees
and
we
were
starting
to
find
that
even
the
object
lookup
was
showing
up
in
the
hot
path,
and
that
was
inspiration
here
from
the
azure
repo
server
to
bring
the
multi
pack
index
to
the
client,
and
so
what
the
multi
pack
index
is
is
kind
of
the
not
so
secret
sauce
of
azure
repos
that
helps
it
scale.
A
Up
to
these
large
repositories.
The
the
service
needs
index
a
lot
of
packs,
efficiently
and
VFS.
Forget
has
a
similar
design,
as
as
these
pack
files
are
created
to
deliver
to
deliver
the
commits
and
trees
from
our
cache
servers
to
windows
developers,
machines,
they
are
accumulating
pack
files
and
has
the
pack
files
were
being
accumulated.
We
were
finding.
We
were
just
taking
more
time
inside
object,
lookup.
Well,
what
multi
pack
index
does
is
really
accelerate
the
time
it
takes
to
find
a
particular
object.
A
Each
pack
has
a
corresponding
pack
index
so,
as
you
increase
the
number
of
packs,
there's
a
corresponding
number
of
pack
indexes
that
you
have
to
roll
through
to
find
the
object
you're.
Looking
for
in
a
normal
repository,
you
know
that
there'll
be
a
handful
of
these
and
it's
not
such
a
big
deal.
You'll
find
these
by
just
going
through
and
probing
all
right.
Do
you
have
my
object?
What
about
you
and
it'll
be
a
binary
search
was
reasonably
quick.
What
about
you?
Okay,
once
I
find
it
then
I
know
I
can
stop
looking.
A
It
has
a
nice
property
of
being
able
to
early
out,
but
even
being
able
to
early
out.
We
were
averaging
these
times
just
creeping
up
to
a
place
where
it
wasn't
wasn't
feeling
great
anymore,
so
we
went
and
put
the
multi
pack
index
in
for
them.
The
multi
pack
index
is
very
similar
to
a
pack
index,
but
it's
got
one
additional
field
which
pack
file
can
I
find
this
in.
A
It
also
encodes,
of
course,
the
offset
and
the
object
ID
the
object,
lookup
proceeds
in
the
exact
same
manner
as
it
does
in
the
pack
index.
A
binary
search
through
the
multi
pack
index
will
point
to
a
row.
The
row
tells
us
both
the
pack
and
the
offset
so
that
lets
us
efficiently
index
hundreds.
You
know
500
up
to
a
thousand
packs
in
a
developer's
working
environment
which
really
kind
of
helps
perfect,
but
aggregating.
All
the
pack
indexes
actually
helped
in
one
other
way.
A
Prior
to
prior
to
multipack
index,
we
had
to
actually
go
in
disable
abbreviations
in
the
route
repo
because
searching
the
pack
files
to
find
the
proper
abbreviation
length
took
too
long
so
just
to
review
how
that
works.
When
we're
going
to
compute
the
abbreviation
we'll
scan
through
each
pack
trying
to
find
the
object,
as
well
as
the
two
bounding
objects,
and
we
need
to
do
that,
so
we
know
well,
how
far
do
I
have
to
go
down
on
that
sha
to
get
a
unique
string.
A
This
has
the
property
that
you
cannot
early-out
the
conflicting
object,
maybe
well
past
the
pack
that
actually
contains
the
object.
So
we
need
to
consider
each
pack
in
the
packs
directory
multi
pack
index
helps
considerably
here,
because
it's
just
one
pack
file
to
look
through
and
we're
able
to
find
exactly
where,
where
the
object
is,
and
we
look
on
either
side
above
and
below,
to
find
whether
or
not
we
can
abbreviate
how
far
to
go
to
get
the
that
unique
abbreviation.
So
it's
also
something
that
we
hope
is
applicable,
the
midok
status.
A
Sorry,
the
multi
pack
index,
we
hope,
is
unique
or
is
available
for
usage
on
on
get
hosting
service
services,
because
this
is
one
of
the
pieces
that
helps
as
your
repos
scale
so
well.
This
is
also
available
in
get
2.20.
You
can
turn
on
get
config
or
not
multi
pack
index
to
true,
and
then
you
can
write
it
with
courgette
multi
pack
index
right.
This
is
one
we
were
really
looking
for
some
feedback
from
the
community
on
this.
A
If
this
is
something
you're
interested
in,
how
do
you
see
yourselves
using
it
so
that
we
can
kind
of
efficiently
plan
where
we
go
spend
some
more
time?
Building
this
we
have
a
few
things
that
we
we
know
we
want
to
do
in
terms
of
incremental,
writes
and,
and
a
few
other
features
to
make
it.
You
know
more
robust
and
quicker
to
deal
with,
but
I
do
look
forward
to
hearing
from
the
community
if
this
is
something
that
you
guys
are
passionate
about
as
well.
A
A
Automation.
The
automation
that
we
talked
about
earlier
was
adding
enough
commits
and
trees
that
these
daily
PAC
files,
the
cache
server,
were
producing
we're
averaging
between
150
and
250
megabytes
each,
and
so
we
needed
to
attack
this
problem
from
from
multiple
angles,
to
be
able
to
actually
get
back
to
a
good
experience
in
the
Windows
repository.
The
first
was
engaging
with
our
partners
in
the
Windows
development
group.
So
Windows
did
an
excellent
job.
A
Once
we
kind
of
went
to
them
and
said
hey,
we
think
there's
a
problem
and
you
know
we
need
your
help
to
fix
this.
The
windows
group
did
a
great
job
going
through
and
auditing,
all
of
their
automation,
figuring
out
ways
to
reduce
the
number
of
commits
that
were
being
created
in
a
repository
in
July.
When
we
really
started
the
effort,
we
were,
you
know,
creating
200,000
commits
in
the
repo,
but
by
January,
creating
just
over
50,000.
These
our
commits
we
attribute
to
automation
in
some
form
or
fashion,
and
it's
still
going
down.
A
A
They
were
overwhelming
our
statistics
and
we
didn't
notice
this
because
we
were
measuring
wrong,
which
is
probably
a
story
for
a
different
conference,
but
we
knew
that
if
we
could
emulate
what
they
did,
we
could
we
could
better
serve
other
users,
so
we
had
regressed
up
to
350
seconds
in
June
and
what
we
did
is
we
immolated
these
users
who
had
good
performance
because
VFS
forget
has
a
long-running
mount
process.
In
the
repository
we
could
offload
that
prefetching
of
commits
and
trees
to
the
background.
A
This
now
means
most
fetches
were,
were
no
ops
and
brought
down
the
p80
and
the
p-52.
You
know
just
under
15
seconds.
I.
Remember
if
I
remember
correctly,
so
that's
been
a
huge
positive
impact
in
in
those
those
developers
lives,
and
we
had
also
hoped
that
prefetching
in
the
background
would
speed
up
push
which
had
progressed
similarly
to
with
the
assumption
that
well,
push
needs
to
walk,
commits
to
discover
what
needs
to
be
pushed.
A
It
didn't
at
all
because
we
didn't
measure
first,
and
this
is
one
of
the
critical
critical
things
that
we
need
to
do
as
devs
building
software,
especially
tuning
for
performance.
Don't
guess
I'm
guilty
of
it
clearly,
but
what
we
have
been
doing
while
we
were
investing
in
fetch,
while
we
were
investing
in
medics,
we
had
also
been
building
out
the
trace
to
API
in
get
what
trace
2
lets
us
do
is
put
timing
blocks
around
very
specific
areas
in
the
code.
It
allows
us
to
get
much
finer
grained
detail
in
our
measurements.
A
So
when
we
initially
rolled
out
to
Windows
the
granule
area,
measurements
we
had
on
developers
can
perf
was
essentially
a
pre
command
hook.
That
says:
hey,
you
know,
status
about
to
run,
here's
its
command
line
and
then
a
post
command
hook.
I'm
all
done,
you
know,
I
succeeded.
It
took
two
and
a
half
seconds
which
is
good
for
reporting
on
the
aggregate
saying
yes,
status
is
generally
okay,
but
it's
not
good
for
digging
in
deep
to
figure
out
where
a
population
is
spending
its
time.
A
So
the
the
Bush
investigation
was
actually
a
perfect
opportunity
to
go
eat.
Our
own
dog
food
here
so
we
went
through
and
we
instrumented
several
blocks
inside
of
the
push
and
then
rolled
that
out
to
the
windows
developers.
So
we
could
find
out
where
they're
spending
time
now.
Interestingly,
it
wasn't
exactly
where
we
thought
it
was
so
why
was
it
slow?
So
look
through
the
things
that
happen
to
push.
First,
we
go
get
the
current
restaurant
service.
We
prepare
a
pack
to
send
there's
there's
three
stages
there.
A
A
Vfs
forget
have
brought
a
good
implementation
of
a
lazily
sparse
work
tree
to
get
now.
What
we
wanted
to
do
is
bring
that
same
sparseness
to
push
to
build
a
foundation
to
talk
about
these
changes,
let's
kind
of
review,
how
push
works
today.
The
first
thing
that
push
needs
to
do
as
its
as
is
doing
its
job
is
walk
from
the
remote
rafts
and
the
reps
that
you're
trying
to
push
to
figure
out,
which
ones
need
to
be
included.
A
Anything
that's
available
on
the
remote
is
uninteresting,
but
anything
that
you're
trying
to
push
the
remote
has
never
seen
before
is
interesting
and
so
git
will
keep
walking
trying
to
find
the
set
of
commits
that
are
novel
to
the
server.
Those
are
the
interesting
commits
and
those
uninteresting
commits
that
are
direct
parents
of
the
interesting
limits
and
the
interesting
commits
kind
of
make
up
the
frontier
of
the
commits
that
need
to
be
under
consideration
when
get
goes
to
build
that
pack
file
to
send
up
once
get
it
established.
The
frontier.
A
The
next
thing
it
does
is
go
through
commit
my
commit
walking
down
the
trees
to
the
objects
marking
them
as
uninteresting.
If
it
they
originate
from
initially
uninteresting
commits,
and
it
does
the
same
thing
for
each
uninteresting
commit
and
then,
when
it
does,
that
object,
walk
for
interesting
commits
it
will
mark
those
new
trees
and
blobs
that
are
novel
to
the
server
as
interesting.
A
That
will
progress
all
the
way
through
until
we've
fully
enumerated
the
set
of
objects
that
are
new
to
the
server.
This
is
a
completely
sane
way
to
do
it
in
a
repository
of
not
unusual
size,
but
what
we
were
seeing
in
the
windows
repository
is
to
find
a
hundred
in
streets
under
100
interesting
objects.
We
were
walking
three
million
uninteresting.
A
A
It
works
on
the
assumption
that
most
developers
don't
touch
most
of
the
tree
in
a
repository
as
big
as
windows,
especially
not
the
usual
case.
In
fact,
most
developers
only
work
in
a
very
small
subset
of
the
tree.
What
they're
specialized
in
and
our
our
motivation
was
trying
to
bring
that
a
little
modified
behavior
to
to
the
push
object
enumeration.
The
new
algorithm
tries
to
early-out
from
descending
through
the
objects
as
quickly
as
it
can,
and
it
does
that
by
moving
the
walk
into
path
space.
A
So
we
go
to
the
route
trees
for
each
commit
in
the
frontier,
and
then
we
move
into
a
directory
based
approach.
We
bring
the
path
into
the
equation,
so
this
tree
on
this
commit
references,
three
paths,
a
B
and
C.
All
of
those
happen
to
be
uninteresting
because
they're
referenced
from
an
uninteresting
commit
and
we
walk
all
the
trees
out
a
particular
layer
in
the
higher
deciding
whether
or
not
the
tree
is
interesting
or
uninteresting.
A
When
we
find
a
path
who
only
contains
uninteresting
trees,
we
can
eliminate
that
entire
path
from
further
walks
and
really
cut
down
on
the
amount
of
data
that
we
need
to
process.
When
we
have
paths
like
be
that
contained
both
interesting
and
uninteresting
trees,
we
need
to
deep
in
there
to
find
out
well
what
else
do
we
need
to
learn?
So
we
pick
up
those
trees
and
continue
processing
them
on
a
path
by
path
basis,
we'll
build
a
hash
map
that
contains
each
o
ID
and
whether
or
not
those
those
objects
are
interesting
or
not.
A
A
It
dropped
the
pack
objects'
time
from
10
seconds
to
under
four
and
it
dropped
the
overall
push
time
from
15
seconds
all
the
way
down
to
eight
and
a
half
and
remember
these.
This
is
for
a
relatively
small
topic
branch,
so
I'm
really
excited
to
see
this
roll
out
to
Windows
developers,
and
it's
also
currently
under
review
up
on
the
mailing
list.
So
if
you
have
opinions
on
this,
we
do
look
forward
to
hearing
them.
A
So
we're
really
hopeful
that
once
we
roll
this
out
we'll
have
that
same
sustained
improvement
in
time
and
push
times
that
we
didn't
fetch.
So
we
move
on
real,
quick
and
touch
briefly
on
another
piece
of
work.
We
did
to
really
bring
the
windows
repository
performance
in
line
with
their
developers,
expectations
and
that's
to
do
to
do
with
status.
A
A
You
know
a
half
a
second
750
milliseconds
up
to
two
and
a
half
three
and
a
half
four
and
a
half
seconds,
and
there
was
general
dissatisfaction
with
that
performance,
and
so
we
took
a
little
bit
of
a
cue
from
how
ideas
handle
this,
because
we
have
the
virtual
file
system
layer
that
sits
right
above
NTFS.
We
can
monitor
for
writes
on
to
the
repository
the
projected
file
system.
A
You
talk
back
to
the
melt
process
and
say:
hey
I,
see
this
editor
just
wrote
this
file
you
may
want
to
do
something
about
it,
which
is
happy
to
do
the
VFS
forgetting
out
process
will
then
go
responsibly,
run
status
and
serialize
the
result
to
a
cache
file.
This
means
that
once
that
result
is
available
when
a
user
queries
for
status,
VFS,
forget
or
actually
get
this
is
all
built
inside
of
git
is
able
to
see
there's
a
cache
file
and
immediately
respond
with
those
results.
A
This
helped
us
move
the
status
perf
of
the
Windows
repository,
which
was
sitting
around.
You
know
three
seconds
the
median
all
the
way
down
to
about
750
milliseconds,
bringing
it
kind
of
more
in
line
with
the
expectations
of
the
developers
and
really
just
kind
of
removing
those
paper
cuts
that
were
introduced
from
the
transition
from
the
centralized
system
to
get
so.
A
Specifically,
we
are
porting
so
that
we
can
host
office,
and
that
means
that
we
can't
rely
on
pledge
of
s,
then
can
rely
on
Windows
and
Mac
doesn't
have
an
equivalent
that
we
found
performed
as
well.
So
we're
writing
a
text
for
Mac
that
simulates
the
behavior
of
EFS
for
project
fess,
but
on
Mac
OS,
and
in
doing
that.
A
The
second
largest
repository
in
the
world
on
devfs
forget-
and
you
know,
I
just
want
to
say
thanks
to
the
geek
community
contributors
and
maintained
errs
for
being
just
you
know
very
welcoming-
and
we
can't
do
this
without
all
the
work
that
the
community
had
done
to
get
to
get
to
this
place
and
I'm
just
really
excited
to
be
a
part
of
continuing
to
make
it
get.
The
version
control
system
of
choice.
Thank
you.