►
From YouTube: Scaling Git at Microsoft - Git Merge 2017
Description
Saeed Noursalehi, Principal Program Manager, Visual Studio Team Services, discusses in depth how Microsoft is using git internally, with a specific focus on large repositories.
He’ll describe the architecture of VSTS’s git server, which is built on Azure, and the customizations Microsoft has had to make to both it and git.exe in order to enable git to scale further and further.
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
In
number-
and
most
of
this
is
just
you
know-
small
teams,
medium
sized
teams
migrating
to
get
there
using
our
git
service,
we've
been
building
up
a
build
infrastructure,
and
you
know
the
most
of
the
pain
that
they
have
is
around
updating
their
own
tools
and
and
educating
their
their
developers
and
there's
some
pain
as
they
migrate
over,
but
across
the
board
once
they
get
there,
you
ask
them,
you
know
what
they
think
about
it
and
the
answer
is
they
would
never
go
back.
So
it's
the
transitions.
A
A
You
know,
and
for
the
past
couple
years,
the
largest
repos
that
we've
had
have
been
about
the
size
numbers
you
see
here,
which
you
know
compared
to
one
of
the
larger
repos
out
there
with
the
linux
repo,
our
own
team,
the
team
services
repo
is
fairly
large
and
we
have
a
handful
of
repos
about
this
sides
across
the
company,
and
so
we
have
you
know.
Three
gigs
of
of
this
is
three
gigs
of
sources
in
the
working
directory
at
the
tip
of
Master.
A
So
this
is
not
with
any
history
or
anything,
and
it's
something
like
350
developers
who
push
to
this
repo
on
a
daily
basis,
and
so
we've
had
to
do
a
lot
of
work
on
in
our
service
to
make
to
make
sure
that
we
can
scale
to
this
size
of
a
repo.
One
really
interesting
thing
that
we've
built
is
a
feature
that
we
call
limited
reps
with
this
many
people
in
a
repo
you
figure,
each
person
is
pushing
5,
10
15
topic
branches;
sometimes
they
remember
delete
them
when
they're
done
and
sometimes
they
don't.
A
And
you
end
up
with.
You
know
thousands
of
branches
in
this
repo,
and
it
just
makes
it
a
pain
for
people
to
work
with
it.
You
know
we
when
you
clone,
or
you
fetch.
You
have
to
fetch
all
these
branches
that
you
don't
care
about,
and
you
try
to
list
your
branches
and
you
got
to
wade
through
a
bunch
of
noise.
A
You
know,
we've
had
to
make
sure
that
our
our
pull
requests
can
keep
up
with
that.
Many
people
merging
into
master
on
a
daily
basis
had
to
get
smarter
about
caching
content
and
we've
done
a
pretty
good
job.
You
know
with
we
have
several
repos
about
this
size
and
and
they're
working
reasonably
well,
and
the
nice
thing
is
on
your
dev
box.
You
know
get
still
does
pretty
well
with
repos.
Of
of
this
size
problem
is.
This
is
not
really
big.
A
This
is
big,
so
I
have
the
windows
team
coming
in
to
a
git
repo
and
their
numbers
just
dwarfed
everything
else
we've
ever
worked
with.
So
now
in
the
working
directory
tip
of
Master.
You
have
three
and
a
half
million
source
files
equals
about
217
gigs
of
sources
when
you
clone-
and
this
is
with
no
history.
Yet
you
have
an
86
gigabyte
PAC
file
in
that
initial
phone.
A
The
index
file,
which
has
a
cache
of
every
pass
of
every
file,
that's
in
a
repo
about
400
megabytes
in
size,
and
so
that
just
makes
everything
you
do
locally,
just
a
paint.
You
know
you,
because
that
will
so
many
of
the
the
local
git
operations
have
to
deal
with
the
whole
index
have
to
read
it
in
scan
through
it,
make
a
change
write
it
back
out.
A
A
You
know,
if
you
lose
your
connection
at
some
point
in
there
you
got
to
start
over
I.
Think
the
last
time
I
try
to
do
it.
It
took
me
four
days
to
clone,
and
then
you
know
you
try
to
check
out
that
first
branch
and
and
it
takes
three
hours
every
time
you
run
status,
and
you
know
if
nothing
has
changed
in
the
repo
and
your
run
git
status,
it's
not
to
take.
It
will
take
8
minutes
to
tell
you
that
nothing
changed.
A
This
is
on
an
SSD
and
say
you
edit
one
file
and
you
do
a
git,
add
and
then
I
get
commit
15
minutes
per,
which
is
the
30
minute
number
I
wrote
up
there.
It's
just
not
usable
right,
not
even
in
the
realm
of
of
sane,
and
so
we
tried
a
bunch
of
different
things
to
to
make
to
make
this
better.
We
played
around
with
the
idea
of
using
an
alternate
object
store.
You
know.
Gate
already
has
this
concept
of
when
it
tries
to
find
an
object.
It
looks
in
a
few
different
places
right.
A
It
looks
for
a
loose
object
in
the
docket
objects
folder.
It
will
look
for
a
pack
file
in
your
packs
folder
and
then,
if
you
configure
an
alternate
path,
if
it
doesn't
find
it
in
those
places
that
we'll
go,
look
in
that
alternate
path
again
for
loose
objects
or
pack
files,
so
we
thought
you
know
what,
if
we
configure
an
alternate
path
that
we
map
to
a
network
chair
and
we
have
a
network
map
array
of
hard
drives
that
have
all
the
objects
already
on
them.
A
So
when
you
clone,
you
don't
have
to
download
the
object,
you
already
have
access
to
them.
We
hit
up.
You
know
a
lot
of
the
sorts
of
tricks
that
we
try
to
play
on
git.
You
know
we
came
up
against
this
problem
that
get
made
a
lot
of
assumptions
that
are
perfectly
reasonable
for
a
normal-size
repo
and
then
we're
trying
to
push
it
way
beyond
those
limits
and
those
assumptions
break
down
and
so
like
with
alternates.
A
You
know
get
assumes
that
you're
actually
pointing
at
another
local
path,
so
it
doesn't
bother
caching,
anything
because
it
figures
that
the
files
are
easily
accessible,
and
so
we
tried
to
you,
try
to
access
objects
and
now
it's
doing
random
access,
IO
on
a
file,
that's
on
a
network
share
and-
and
so
the
latency
is
awful
and-
and
it
still
tries
to
you-
know
you
callin-
it
doesn't
copy
any
files
locally,
but
it
still
wants
to
make
sure
that
it's
all
valid,
so
it
still
reached
through
the
whole
thing.
It
just
doesn't
really
work
out.
A
You
know
we
tried
taking
this
giant
repo
and
splitting
it
up
into
a
bunch
of
smaller
ones
and
then
having
some
some
other
tooling,
that
kind
of
stitches
them
all
back
together
when
you
want
to
build
and
that
just
you
know,
it
works
for
some
limited
scenarios,
but
it
causes
a
lot
of
pain.
For
one
thing,
you
can't
ever
do
any
massive
refactoring
and
that's
something
that
the
windows
team
is
very
interested
in
doing
because
you
trying
to
refactor
across
those
arbitrary
boundaries.
You
introduced
a
lot
of
a
lot
of
pain
in
your
developer.
A
Workflow
we
even
looked
at
you
know:
things
like
LFS
and
LFS
doesn't
really
make
a
dent
in
this
problem.
You
know
you
can
reduce
the
size
of
that
hack
file
a
little
bit,
but
it
doesn't
reduce
the
number
of
files
in
a
working
directory.
It
doesn't
make
the
index
any
smaller,
so
we
realized
that
we
have
to
kind
of
step
back
and
think
of
this
problem
differently,
and
so
the
idea
that
we
came
up
with
was
to
just
virtualize
the
file
system
underneath
the
repo.
A
So
that's
what
I
want
to
get
into
in
some
detail
here.
We
built
this
this
file
now
on.
For
now
it's
on
Windows
we're
looking
at
expanding
that.
But
what
we
do
is
we
virtualized
the
whole
file
system
beneath
your
get
refill
so
that
it
looks
like
all
the
files
are
there
and
we
play
some
tricks
on
git,
so
that
git
doesn't
bother
looking
at
necessarily
at
all
the
files,
and
then
we
download
the
files
on
demand
when
you
need
them
now,
all
of
a
sudden,
your
get
operations
on
that
same
repo,
look
very
different.
A
You
know
it
takes
a
few
minutes
now
to
clone
and
that's
the
one
command
that
we
changed
was
we
have
a
new
verb,
gvfs
clone
instead
of
git
clone
everything
else,
you're
just
using
regular,
get
on
top
of
this
file
system,
and
so
we
can
clone
in
a
few
minutes,
because
all
we're
downloading
is
a
commit
object
and
all
the
trees
which
all
of
those
objects
are
tiny
and
then
from
the
trees.
We
can
project
the
whole
working
directory.
We
know
the
shape
of
all
the
files
in
the
repo,
so
clone
takes
no
time.
A
A
You
know
with
the
smarts
checkout
file
you
can,
if
you
list
a
set
of
pads
in
there
before
you
do
a
checkout,
it
will
only
write
out
those
files
into
the
working
directory
and
it
marks
everything
else
in
the
index
as
ignored,
and
so
then,
when
it
does
a
status
or
check
out
or
whatever
it
only
considers
the
files
that
it
thinks
it
wrote
out.
It
assumes
that
everything
else
was
not
even
written
into
the
working
directory.
A
A
We
still
have
some
some
bugs
with
with
these
things
like
sometimes
git
will
decide
like
we
just
hit
a
bug
where
you
do
run
git
status
and
and
it
takes
an
hour
and
a
half,
and
it's
because
it
kind
of
went
down
them
a
rename
detection
path,
caused
it
to
start
downloading
lots
of
blobs
everywhere
and
we're
fixing
all
those
sorts
of
things.
So
we're
not
done
yet,
but
we
are
seeing
numbers
that
now
are
in
the
realm
of
possible
and
we're
still
trying
to
make
these
faster.
A
I'm
also
excited
to
say
that
it's
all
going
to
be
open
source
I
mean
actually
as
soon
as
I
get
off
the
stage
here.
I'm
going
to
go,
publish
these
links,
don't
bother
going
there
just
yet,
but
it'll
be
live
in
just
a
few
minutes.
The
only
URL
that
you
have
to
memorize
is
that
top
one.
If
you
go
to
aka.ms/offweb.
A
To
publish
that
has
all
the
rest
of
the
links
in
it,
and
so
the
the
gpfs
client-side
code
is
all
going
to
be
open.
We
also
rely
on
a
kernel
mode
filter
driver
that
we're
trying
to
figure
out
the
best
means
of
releasing
that
it's
available.
If
you
want
to
test
it
out
as
a
pre-release
preview,
the
driver
is
but
the
code
for
gvfs
itself
is
available.
A
So
let's
talk
about
how
gvfs
works.
The
first
thing
I
already
alluded
to
is:
we
have
a
file
system
driver
and
it's
made
up
of
two
components:
there's
a
kernel
mode
component
and
a
user
mode
component.
The
kernel
mode
part
of
it
doesn't
know
anything
about
git.
What
it
does
is
it
it
allows
you
to
create.
A
This
is
an
NTFS
extension
basically,
and
it
allows
you
to
have
a
folder
on
disk
that
is
only
partially
populated
and
then,
when
you
try
to
enumerate
it,
it
will
ask
a
user
mode
application
to
enumerate
the
contents
of
that
folder.
If
that's,
where
we
come
in,
is
we
then
go
and
examine
the
git
trees
and
figure
out
what
objects?
You
know
what
subfolders
and
files
should
be
enumerated
into
that
folder
and
then
one
of
these
virtual
files
that
are
being
shown
in
the
in
the
directory
when
a
user
tries
to
open
them.
A
When
you
know
you
should
use
your
IDE
or
a
build
tool
opens
it
or
whatever
the
that
Colonel
limo
driver
will
then
ask
our
user
remote
process.
Give
me
the
contents
of
this
file
and
we'll
look
in
our
local,
get
cache
or
lots
of
service
through
the
protocol
that
we've
got
and
download
the
contents
and
write
it
into
the
file
and
after
that,
it's
just
a
normal
file
on
disk.
So
the
other
thing
that
we
do
here
in
our
user
mode
part
of
this
is
we
manage
the
sparse
checkout
right.
A
A
We've
also
added
a
new
feature
to
get
called
the
read
object
hook.
So
I
mentioned
before
that
when,
when
gate
is
looking
for
objects,
it
looks
in
the
docket
folder,
the
docket
objects
folder
for
loose
objects,
and
then
it
looks
in
the
packs
folder
and
then
it
looks
for
alternates.
And
finally,
if
it
doesn't
find
the
object
in
any
of
those
places,
it'll
call
this
new
hook.
A
Even
if
you're
sparse
check
out
only
has
one
file
in
it
and
it
just
had
to
write
that
one
file
a
disk
afterwards.
It
tries
to
make
sure
that
your
repo
is
healthy
and
so
it'll
scan
through
all
the
trees
and
all
the
blobs
that
are
referenced
by
that
commit
and
just
make
sure
they
all
exist
on
disk
and
when
you're
in
a
virtual
file
system,
just
checking
that
they
exist
means
you're,
opening
them,
which
means
we're
downloading
them
all.
A
We've
also
made
you
know
to
make
all
this
work.
We've
created
a
new
protocol
that
I
talked
about.
It's
just
an
extension
that
you
can
go
and
ask
for
a
single
blob
or
a
single.
You
know
object.
You
can
also
ask
for
the
size
of
the
blobs.
We
need
that
one
more
and
numerating,
and
one
thing
that
you
really
need
to
make
all
this
work.
You
know
one
trade-off
that
we're
making
is
because
you're,
not
downloading
everything,
upfront,
you're
downloading
the
files
on
demand,
we're
creating
some
extra
latency
in
accessing
those.
A
But
when
you
access
the
file
the
first
time
and
that
latency
really
adds
up
like
if
you
do
a
clone
and
then
you
try
to
run
a
build
that
touches
a
hundred
thousand
files
and
on
every
single
file,
you
have
to
make
it
you're,
making
a
call
to
the
server
to
download
the
contents
that
just
really
adds
up,
and
so
in
order
to
make
it
all
really
work
for
the
user.
You
really
need
to
catch
those
contents
close
by.
So
we
built
a
cache
server.
A
It's
just
a
caching
proxy
for
that
protocol
that
we
use,
but
it
really
makes
things
a
lot
nicer
for
the
user
and
we've
been,
you
know,
making
a
lot
of
these
changes
that
actually
benefit
all
get.
Users
like
these
are
just
a
list
of
pull
requests
that
we've
submitted
already
that
just
make
get
faster
in
Scenario,
then
it's
not
even
related
to
gvfs.
A
Earlier
the
Wi-Fi
was
kind
of
in
and
out
so
we'll
see
if
this
works
well,
so
first
of
all,
I'm
just
going
to
show
you
and
I'm
going
to
demo
this
with
some
the
VSO
repo,
not
the
Windows
repo.
So
this
is
that
repo,
that's
about
three
gigs
in
size
and
I've,
got
here:
I've
pre
cloned
it
in
two
different
ways.
A
A
So
there's
just
there's
a
single
pack
file
about
eight
gigs
in
size,
and
you
know
that
index
was
about
16
Meg's,
like
I
said
before,
and
if
I
I
won't
stay
here
and
make
you
watch
all
of
it,
but
you
can
see
that
it's
going
to
keep
counting
up.
There's
our
three
gigs
of
of
sources
there,
one
hundred
one
hundred
twelve
hundred
thirteen
thousand
files
or
something
now
I've
got
the
same
repo
that
I've
cloned.
But
it's
not
mounted
so
right
now.
A
You
won't
see
any
contents
in
here
on
GV
SS,
and
this
is
that
same
working
directory,
there's
only
one
file
in
there
the
get
attributes
file
when
we
cloned
it.
We
went
ahead
and
put
that
file
on
disk.
We
actually
made
sort
of
one
major
constraint
of
using
GPSS.
Is
we
don't
allow
any
clean
or
smudge
filters,
because
that
makes
it
really
hard
to
reliably
project
a
file?
A
If
you
can
arbitrarily
change
it
as
soon
as
you
check
it
out,
but
so
there's
one
file
in
there
I
go
to
the
dog,
get
objects
folder,
and
you
see
that
that
one
that
one
object
is
laid
out.
That's
that
get
attributes,
file
and
I
have
about
a
an
80
megabytes
tag
file
that
just
has
all
the
the
tree
objects
for
the
two
most
recent
commits
in
it,
and
that's
it
right.
So
from
that
the
and
I'll
show
you
the
contents
of.
Let
me
go
into
that
folder.
A
Look
at
the
contents
of
the
sparse
check
out-
and
this
is
where
a
lot
of
that
magic
happens
right
now.
It's
saying,
there's
just
that
one
file
right
and
so,
and
so
gif
thinks
get
this
gets
happy.
It's
only
that
won't
file
exists
on
disk
and
that's
all
it
cares
about.
But
let
me
go
ahead
and
now
mount
and
you
know
you'll
see,
there's
nothing
in
here,
except
for
that
file.
A
Part
of
what
it's
doing
right
now
is
it's
checking
with
the
server
to
make
sure
that
its
client
version
is
is
not
too
outdated,
and
the
network
here
is
giving
me
a
little
trouble.
Give
it
a
minute
once
this
is
done
mounting
what
it's
going
to
do
is
it's
going
to,
then
you
know,
examine
the
the
tree
to
get
tree
for
the
current
commit
that's
checked
out
and
from
that
we
can
project
the
whole
shape
of
the
of
the
working
directory.
Of
course,
if
it
doesn't
connect,
that's
not
going
to
work.
A
Part,
some
of
the
challenges
that
we've
had
to
face
in
making
this
work
is
just
that
that
index
file
is,
is
a
real
pain
point.
It's
for
you
know
in
the
Windows
repo,
it's
four
hundred
megabytes
and
when,
whatever
we
hydrate
a
file,
we
have
to
update
the
index
to
clear
the
skip
work
three
bit
on
that
entry
and
there's
no
three
and
a
half
million
entries
in
there.
The
way
it
normally
updates
the
index-
and
this
is
mounted
I'll-
get
to
it
in
a
sec.
A
The
way
it
normally
deals
with
index
changes
is,
it
always
writes
the
new
index
to
an
index
dot
log
file
makes
whatever
changes
the
needs
in
there
and
then
copies
it
over.
You
know
renames
it
with
to
delete
the
old
index
and
overwrite
it
with
a
new
one,
rewriting
400
megabytes.
Every
time
we
want
to
change,
one
bit
is
very
inefficient,
and
so
we've
had
to
get
very
clever
with
with
how
we
do
that,
but
still
play
nice.
A
So
we
just
like
create
an
empty
index,
dot
log
file,
we
parse
the
the
index
file
and
remember
the
offsets
of
every
entry,
and
so
we
can
quickly
get
to
it
and
update
it.
So
we've
had
to
do
a
lot
of
optimizations
there
anyway.
So
this
is
not
mounted
and
there's
the
the
debug
window
and
now
I'll
enumerate
and
you'll
see
that
it's
asking
the
server
for
the
sizes
of
the
children--
entries
in
that
folder.
But
there's
all
the
entries
now
and
so,
even
though
it
was
empty
and
it
still
is
empty.
A
A
It's
all.
It's
all
just
right
there
and
I'll
open
another
one,
make
some
changes
and
and
save
it
and
run
git
status.
And
you
know
it
knows
that
F
to
change
that
file,
so
everything
still
kind
of
works
like
normal
and
you'll.
You
might
have
noticed
that
as
I
ran,
get
status
had
downloaded
one
more
file
that
was
get
always
get
status
always
wants
to
see
you're
getting
Nora
files,
that's
the
one
it
when
downloaded.
A
Let's
go
ahead
and
unmount
this
and
we'll
see
what
state
were
left
in
now
you
see
there's
some
actual
files
sitting
on
disk
here.
Right
I
did
the
get
attributes
from
before
they
get
ignore
that
it
is
downloaded
and
then
the
both
the
one
file
that
I
touched.
It
has
to
create
the
folders
to
contain
them
and
are
the
two
files
and
they're
the
two
files.
Now
that
are
just
real
files
on
disk
and
if
I
look
at
the
sparse
check
out
all
the
files
that
we
hydrated
are
now
in
there.
A
A
What's
next,
is
you
know
we
keep
keep
plugging
away
at
that
performance.
We
have
on
that
giant,
Windows
repo.
We
have
a
handful
of
users
who
have
been
our
brave
early
adopters
and
they
keep
telling
me
when
they
find
some
corner
case
where
we
go
in
download
three
and
a
half
million
blogs
and
we
go
fix
them
and,
and
we
keep
getting
closer
over
the
actually
this
weekend,
we're
going
to
be
deploying
to
another
round
or
about
150
people.
This
weekend
are
going
to
be
coming
into
that
repo
and
over
the
next.
A
A
A
Perf
is
the
next
thing
we
got
to
make
sure
that
you
know
developers
are
not
getting
blocked,
waiting
on
on
the
performance
there
and
after
that
you
know
we're
going
to
start
picking
away
at
tools
that
use
git
and
make
sure
that
they're
happy
and
if
the
top
two
are
going
to
be
Visual,
Studio
2017
and
get
K.
Those
are
the
two
of
the
most
common
ones
that
our
own
users
use
and
the
rest
will
kind
of
depend
on
demand.
A
We
definitely
are
hearing
demand
that
we
should
support
gvfs
on
Mac
and
Linux.
So
that's
something
we're
looking
hard
at.
If
anybody
out
there
knows
about
file
systems
on
those
platforms,
come
talk
to
me.
We're
definitely
we're.
Definitely
hiring
and
that's
it
time.
I
think
I
have
a
couple
minutes
for
your
questions.
If
anybody
had
any
out
there,
yep.
A
You
know,
for
the
most
part,
we've
we've
tried
to
leave
the
behavior
of
get
unchanged
and
just
make
it
so
that
the
the
file
system
makes
it
bring
things
in
as
you
access
them,
and
so
for
something
like
you
know,
for
those
sorts
of
historical
tools,
the
commands
and
get
its.
It
poses
an
interesting
challenge.
You
know
with
git
log,
for
example,
you
know
I
just
tries
to
walk
through
all
the
objects
locally
and
it
could
be.
It
could
be
kind
of
painful,
so
part
of
what
we
did
there
to
make
it
work
nicer.
A
Is
we
actually
prefetch
your
history
of
commit
objects
because
they're
tiny
and
we
can
just
download
them
all
in
one
in
one
tack-
file
and
get
log-
will
have
access
to
them,
at
least
for
the
commit
history
for
the
blob
history.
It
has
to
go
and
look
at
the
each
blob
individually
and
we've
talked
about
being
it
like
prefetching
certain
certain
blobs
in
order
to
make
that
better,
I
haven't
really
thought
about
something
like
that
of
like
taking
a
command
that
you
would
normally
run
locally
and
shuttling
it
off
to
the
server.
A
A
A
A
Ninety-Nine
percent
of
people
don't
work
across
all
the
sources,
the
vast
majority.
What
they
do
is
they
only
have
to
work
in
some
in
some
like
two
or
three
levels:
down
subfolder,
that's
where
they
spend
all
the
time-
and
you
know
nobody
ever
like
clones-
the
repo
and
builds
the
whole
thing
right.
That
would
that
would
be
madness.
A
You
know
fifty
to
a
hundred
thousand
files
and
we
can
hydrate
those
pretty
quickly
and
you
know
so
in
reality,
like
that's,
where
you're
going
to
be
doing
your
searches,
is
you
know
you
the
same
set
of
file
that
you're
going
to
be
building,
or
also
where
you're
generally
going
to
be
searching?
We
also
actually
have
I
mean
the
windows
team
has
a
lot
of
infrastructure
built
up
around
their
codebase
and
they
actually
have
really
fast
server-side
searching
capabilities.
A
A
Sure
so
yeah
the
question
was
about
about
limited
rep.
Actually
we
didn't
modify
get
to
enable
limited
reps.
We
only
modified
how
we
respond
to
the
m4s,
and
so
we
didn't
have
to
change
the
client
side
at
all.
But
the
question
was:
when
you
have
limited
reps,
how
is
that
different
than
just
having
Forks
in
a
lot
of
ways?
It
looks
similar.
A
You
know
with
with
limited
reps,
if
you're
in
a
team
of
people
that
that
are
all
trusted,
they're
all
everyone's
authenticated
and
on
the
same
team,
and
all
that,
if
I
want
to
see
somebody
else's
branches,
I
just
go
to
the
web
and
favorite
their
branches,
and
now
I
I
cloned
them
a
role
in
the
same
repo.
So
there's
just
there's
fewer
hurdles
in
sharing
our
code
with
each
other
versus
compared
to
Forks.
So
I'm
all
out
of
time
here,
happy
to
take
questions
later
on.
If
you
find
me
in
the
hallway,
so
thank
you.