►
Description
Durham Goode is the tech lead on the Source Control team at Facebook. Facebook uses Mercurial to host some of the largest, fastest growing distributed version control repositories in the world. Over the past four years, they've dealt with numerous scaling challenges, ranging from the number of commits per minute to creating robust, redundant server infrastructure. Facebook has also introduced significant user experience improvements to make it easier to ramp up new engineers and to make power-user workflows more accessible to everyone.
In this session, Durham will talk about the specific technical and user experience improvements Facebook has open sourced to handle their growing scale, with an emphasis on the lessons learned that could be valuable to Git and the Git community.
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
Like
he
said,
my
name
is
Durham
I'm
on
the
sword,
control
team
at
Sage,
book
and
I
know
it
says
scaling
get
at
Facebook,
but
we
don't
actually
use
get
at
Facebook.
We
use
mercurial
and
that's
the
slide.
He
was
talking
about
that
took
two
hours
to
make
that
thing
fall,
and
so
this
talk,
it's
not
going
to
be
about
why
we
use
mercurial.
You
can
find
that
out
online.
A
We
did
a
blog
post
and
it's
not
going
to
be
about
why
we
use
mana
repos,
there's
many
blog
posts
that
cover
that
instead,
I
want
to
talk
about
the
specific
technical
things.
We've
done
around
scaling
our
repo
and
scaling
our
user
experience
that
I
think
would
be
applicable
to
get
community
and
that
I
kind
of
hope
to
get
community
adopts.
So
we
can
kind
of
move
forward
together
in
this
version
control
world.
But
first
you
kind
of
have
to
have
some
context
about
our
repositories.
A
For
one
we
use
mono
repos
we've
got
two
of
them:
one
is
FB
source,
that's
kind
of
our
mobile
and
our
back-end
and
a
bunch
of
other
stuff.
The
other
is
WW,
or
that
is
our
front
end
of
facebook.com/,
the
PHP,
the
JavaScript
all
of
that
stuff,
and
that's
where
the
vast
majority
of
all
commits
go
into
one
of
those
two
repositories.
The
second
thing
you
need
to
understand
is
that
we
don't
use
feature
branches
really
locally.
People
use
them,
but
there's
no
feature
branches
on
the
server
that
are
persisted
for
any
amount
of
time.
A
A
If
you
don't
know
hg,
that's
the
symbol
for
the
command-line
interface
for
mercurial
30%
shorter
than
get
so
that's
an
immediate
perf
win,
but
we
use
exclusively
rebase,
--is
and
kind
of
a
corollary
of
that
is
that
we
do
single
commits
you
don't
make
a
stack
of
commits
and
then
like
merge
that
in
instead,
you'll
have
a
single
commit
that
is
small
and
incrementally
moved
the
repository
forward.
That
is,
code
review,
two
passes,
the
build
passes
the
tests
and
it
results
in
this.
A
You'll
see
we
tend
to
assume
our
developers
are
online
and
some
of
the
scalability
things
we
do
are
around
the
online
experience
and
we
take
advantage
of
that
they
can
work
offline.
So
we
don't.
We
don't
take
that
away,
but
you'll
see
that
we
do
orient
ourselves
towards
our
developers
being
online
if
you're
familiar
with
mercurial,
you
know
there's
bookmarks
and
there's
branches,
we
use
bookmarks.
If
you
don't
know
what
mercurial
is
it's
another
distributed
version
control
system?
If
you
don't
know
what
these
words
are,
don't
worry,
bookmarks
are
just
like
git
branches.
A
So
any
time
I
say
the
word
bookmark
just
pretend
I
said
branch
and
it
just
works
just
like
it.
And
lastly,
we
ship
the
absolute
latest
version
of
mercurial
now
I,
just
like
the
last
release,
but
we
ship
today's
latest
master
branch
to
all
of
our
users
and
then
we
layer
some
extensions
on
top
to
improve
scalability
and
change
them.
A
The
user
experience
and
I'll
talk
about
kind
of
the
ways
in
which
we
change
it,
so
we
are
shipping
very
latest
mercurial,
and
hopefully
this
gives
you
a
bit
of
context
of
how
we
work
and
kind
of
sets
sets
the
context
for
what
you'll
see.
As
we
talk
about
some
of
these
problems,
we
have
the
first
problem
is
of
scale
and
there's
tons
of
axes
of
scale
in
version
control.
You
have
too
many
files
too
many
files
of
history,
too
many
commits
to
many
commits
per
hour.
A
Your
files
can
be
too
big
and
we
have
to
address
all
of
those
as
part
of
making
our
repository
scale
to
our
growing
company
and
our
needs
of
the
future,
and
unfortunately,
I
can't
actually
tell
you
how
big
the
repository
is,
which
is
a
real
shame,
but
what
I
can
tell
you
is
that
think
of
the
biggest
git
repo
you
have
ever
heard
of
and
we
are
bigger.
This
is
the
biggest
gift.
A
This
is
the
biggest
distributed
version,
control
repository
I've
ever
heard
of,
and
to
give
you
an
idea
of
how
fast
it's
growing,
even
though
it's
already
big,
this
is
a
chart
of
a
number
of
files
in
the
repository
over
time
from
2008
to
2016.
I
got
hired
right
around
that
little
blip
at
the
bottom
and
I
was
already
scared,
and
now
the
curve
is
only
going
up
and
that's
the
worst
part
about
version
control.
Is
you
never
delete
anything
so
that
it
only
ever
goes
up
and
we
need
to
scale
to
meet
that
growing
demand?
A
Now
the
other
side
of
the
problem
area
area
is
user
experience.
We
are
hire
hundreds
of
engineers
and
we
have
two
onboard
hundreds
of
Engineers
and
there's
only
like
a
few
people
on
the
source
control
team,
so
customer
support
doesn't
scale
and
the
current
command-line
interfaces
there
I
think
net
would
be.
A
It
would
be
a
conservative
way
to
describe
them
for
both
good
and
mercurial
they're,
not
great,
and
what
we
need
is
a
user
experience
that
is
easy
to
learn
trivial,
to
recover
from
and
makes
power
user
workflows
available
to
even
novice
users
and
so
later
I'm
going
to
talk
about
kind
of
the
ways
in
which
we've
done
that,
and
hopefully
it
can
take
advantage
of
some
of
those
same
things.
First
off,
though,
I
want
to
talk
about
the
details
of
how
we
scale
oh
I
have
a
clicker.
It
doesn't
work,
that's
all
right.
A
The
first
thing
I
want
to
talk
about
is
push
contention
and
I.
Think
a
previous
speaker
alluded
to
this,
but
basically
push
contention
is
when
you
as
a
developer.
You
want
to
push
so
you
pull
rebase
on
top
and
attempt
to
push
and
if
anyone
else
has
pushed
in
that
interim,
you
have
to
try
again
and
when
you
have
thousands
of
developers
all
doing
this
at
once.
A
You
end
up
with
these
really
long
queues
of
people
waiting
and
waiting,
and
it
becomes
a
huge
productivity
bottleneck
and
we
can't
have
our
users
waiting
on
source
control
like
this,
so
the
way
we've
solved.
This
is
with
the
mercurial
extension.
We
call
push
rebase
and
basically,
it
allows
the
server
to
perform
a
rebase
for
you
in
certain
conditions.
So
in
this
example
here
commit
X
is
on
the
client.
We
want
to
push
it
to
the
server,
but
the
server
has
the
master
C.
A
So
when
you
push
it,
the
server
accepts
it
rebase
is
it
for
you
and
then
send
all
of
that
data
back
to
the
client,
and
now
the
client
receives
the
updated
X
and
the
push
is
complete
and
the
user
did
not
have
to
have
the
latest
master.
So
this
allows
many
people
to
push
it
once
and
avoids
the
push
contention
problem
that
get
in
recur.
A
Mercurial
currently
have-
and
this
has
basically
solved
push
contention
for
us-
to
show
you
kind
of
how
much
this
is
number
of
commits
per
hour
in
some
of
our
biggest
repositories
that
bottom
orange
line.
That's
number
of
that's
a
git
repo
before
we
merge
it
all
together
and
you
can
see
at
the
beginning
of
the
day
it
hits
Peaks
maximum
throughput
and
it
stays
pegged
at
the
maximum
possible
commit
throughput
throughout
the
whole
day.
So
the
work
ends
the
blue
line
above
it
that
is
FB
source.
A
That
is
when
we
have
merged
repositories
together,
move
to
mercurial,
move
to
push
rebase
and
we're
handling
four
times
as
many
commits
per
hour
as
we
previously
were
and,
more
importantly,
the
line
doesn't
cap
out,
so
we
have
not
hit
our
maximum
possible
throughput
yet
so
we
have
more
room
to
grow.
So
this
is
really
important
for
us
being
able
to
make
FB
source
of
viable
mono,
repo
and
scale
to
thousands
of
users.
A
Now
this
basically
like
I,
said
solve
push
contention.
It
also
works
with
merge
commits.
So
if
you
come
from
a
pull
request,
type
workflow,
where
you
have
a
branch
and
you
do
a
pull
request
and
a
merge
comes
in
it-
can
rebase
the
merge
commit.
So
it's
not
limited
to
the
rebase
workflows
that
we
use.
It
can
also
work
in
kind
of
your
standard.
Github
work,
your
standard,
github
kind
of
flow,
it
also
has
a
nice
benefit
benefit
of
moving
hooks
out
of
the
critical
path.
A
A
This
allowed
us
to
move
the
hook
due
before
the
rebase
before
the
critical
path,
and
we
can
run
it
in
parallel
on
everyone's
pushes
at
the
same
time,
and
then
only
afterwards
in
the
rebase
push
part,
just
the
critical
section
only
that
matters
so
hooks
no
longer
affect
our
total
commit
throughput.
So
what
is
stopping
it
from
doing
the
same
thing?
Not
much
actually
I
think
all
get
would
need.
A
Is
the
ability
to
return
a
commit
during
a
push,
and
if
it
could
do
that,
this
fall
is
very
easily
from
there,
and
this
is
kind
of
a
theme
of
the
talk.
Is
that
a
lot
of
you
things
are
really
within
gets
reached?
It
could
easily
be
done
with
just
a
little
bit
of
elbow
grease,
so
push
rebase
allows
our
users
to
push
as
frequently
as
they
want.
A
Now
that
introduces
a
new
problem,
which
is
our
users
are
pushing
as
frequently
as
they
want,
which
means
we
have
this
huge
repository
and
get
it's
a
dot,
git
directory
and
recur
with
about
HG
directory,
and
we
realize
it
kind
of
breaks
down
into
two
parts.
One
is
the
commitment
of
data
and
the
other
is
the
file
content,
and
if
you
look
at
the
ratio
of
these
two
things
commit
metadata
is
a
teeny
teeny
slice
and
file.
Constance
is
everything
and
users.
A
They
don't
need
the
file
content
from
a
month
ago,
much
less
a
decade
ago.
Yet
we
download
every
single
client
every
single
time
they
clone
so
to
address
this
kind
of
problem
to
help
our
scaling
issues.
Week
created
this
thing,
we
call
remote
file
log
and
the
way
it
works
is
basically.
This
is
how
we're
curl
structures
it's
data,
there's
a
bunch
of
commits
there's
a
bunch
of
manifest
manifests,
are
kind
of
like
a
gift
tree.
It's
a
list
of
file.
A
That's
in
each
commit
and
then
there's
all
the
file
content
for
all
the
revisions
that
any
file
has
ever
had.
So
what
we
did
is
instead
of
just
cloning,
everything
like
normal.
We
just
don't
clone
everything
we
only
download,
commits
and
manifest,
which
is
tiny,
very
similar
to
a
Microsoft
described
by
earlier
and
then
on
demand.
A
We
grab
the
exact
revisions,
you
need
and
we
put
them
in
a
cache
and
we
can
prune
that
cache
if
it
gets
too
large
and
we
can
redownload
them
from
the
server
and
we
can
start
to
play
around
with
this,
and
so
this
has
a
lot
of
benefits.
Mainly,
it
allows
us
to
take
our
big
repo
and
start
treating
it
like
a
small
repository,
especially
with
like
a
sparse
checkout,
where
you
only
checkout
certain
files.
A
Now
you
are
checking
out
certain
files
and
downloading
certain
files
and
the
time
complexity
of
all
these
operations
starts
to
change
and
you'll
see
this
theme
throughout
all
the
scalability
improvements
we
do
is
that
the
problem
is
not
that
murkrow
them
python
and
get
some
see.
The
problem
is
that
time
complexities
are
hard
and
we
need
to
make
better
algorithms,
and
this
is
the
start
of
this.
A
It
also
lets
us
do
this
cool
thing
where
we're
starting
to
take
advantage
of
both
the
advantages
of
centralized
version,
control
and
distributed
version
control,
so
centralized
lets
us
keep
things
on
the
server
and
fetch
them
at
will
and
distributed.
Lets
us
make
offline
commits
and
do
peer-to-peer
pushes
and
all
that
continues
to
work,
we're
starting
to
blend
them
into
this
hybrid
and
getting
the
advantages
of
both
and
I.
A
Think
there's
some
really
interesting
workflows
that
are
going
to
kind
of
come
from
this
unioning
that
we're
doing
so
push
rebase
lets
our
users
push
as
frequently
as
they
want
we're
about
file
log
less
than
push
as
much
as
they
want.
You
think
we'd
be
done,
but
now
our
users
want
to
push
as
many
branches
as
they
want
and
we
have
a
lot
of
users.
It's
a
lot
of
branches.
We've
got
release
branches.
Every
week,
every
product,
new
release
branch
we've
got
scratch
branches
like
every
hackathon.
Every
team
wants
to
make
a
scratch
branch.
A
We
have
a
few
feature:
branches,
I
told
you.
We
don't
use
them
much,
but
there
do
exist
a
few,
and
if
you
push
a
lot
of
these
eh,
it's
a
lot
of
data,
but
be
certain
algorithms
don't
scale.
Well,
when
you
have
hundreds
of
thousands
of
branches,
and
some
people
have
talked
here
about
how
get
refs
work
in
this
same
way,
and
so
we
don't
want
to
have
all
of
that
on
the
server
to
fix
this.
We
created
another
extension,
called
infinite
push
and
I
really
like
the
name,
because
it
sounds.
It
sounds
really
cool.
A
But
now,
when
you
push
a
branch
of
the
server
of
a
certain
type
like
it
may
have
a
scratch
slash
in
front
of
it,
instead
of
putting
it
on
the
server
the
server
redirects
it
to
a
scalable
blob
store,
which
is
you
know,
something
where
we
can
put
basically
infinite
amount
of
data
in
there.
So
the
file
content
goes
in
the
blob
store.
The
metadata
goes
in
sequel,
which
is
also
rather
scalable,
and
this
basically
allows
us
to
have
an
unlimited
number
of
user
branches
that
by
itself
you
know
it's
kind
of
cool.
A
But
it's
somewhat
of
a
parlor
trick:
git
could
do
this.
Usually
what
I
really
want
to
talk
about,
though,
is
the
ramifications
of
this
technology.
This
we
built
the
ramifications
were
building,
so
this
is
kind
of
future-looking.
One
of
the
ramifications
of
being
able
to
push
an
unlimited
number
of
commits
is
why
don't
we
just
push
all
the
commits
if
the
user
types
HD
commits
behind
the
scenes,
we
will
push
it
for
them
into
this
flop
store,
and
now
it's
on
the
server
and
available
to
everyone.
I
could
literally
type
HG
commit
copy.
A
The
hash
message
it
to
my
buddy
and
he
can
type
HG
check
out
that
hash
and
it
would
just
work
no
pushing
no
pulling
so
it's
almost
it's
breaking
down
the
barrier
between
my
repository
and
his
repository
and
the
service
repository
and
making
it.
So
we
can
all
kind
of
interact
and
data
can
flow
freely
without
any
effort
on
the
user's
part
it
lets
you
do
cool
things
like
recover
commits
trivially,
you
lose
your
repository.
A
No
big
deal
clone
a
new
one
check
out
your
bookmark
you're
done
it
lets
you
do
things
like
synchronizing
between
machines,
trivially
work
on
a
bookmark
here,
put
to
that
machine,
your
laptop
your
desktop
work
on
the
bookmark
there
and
it
just
works
the
data
flows
very
easily.
It
has
ramifications
on
automation.
What,
if
every
time
you
made
a
commit,
it
went
off
into
the
cloud
and
the
build
ran.
A
The
test
ran,
the
static
analysis
ran
and
it
came
back
and
annotated
your
IDE
with
the
results,
and
so
now,
like
automation,
can
start
to
play
in
your
client-side
developer
environment,
while
you're
still
using
distributed
version
control.
It
lets
services
start
to
participate
in
this
commit
cloud,
so
you
could
have
a
code
review
UI
where
I
as
a
reviewer
want
to
that
suggests.
A
So
that's
the
end
of
kind
of
the
scalability
portion.
These
are
three
main
things
that
I
think
it
could
easily
adopt
and
do
a
very
similar
concept.
I
know,
Microsoft
has
headed
in
this
direction
already
so
I'm
excited
to
see
that
on
the
user
experience
front,
I
think
it
also
has
a
lot
of
work
to
do
and
we
as
a
source
control
team
at
Facebook,
have
a
lot
of
work
to
do.
A
Like
I
said,
we
hire
hundreds
of
Engineers
and
it
just
doesn't
scale
for
us
to
support
them
all
manually
I'm,
going
to
talk
about
a
few
things.
We've
done
in
specific
about
user
experience
to
make
it
scale
better.
The
first
is
around
log
log
is
like
the
first
command
you
learn
after
clone,
and
all
it
tells
you
is,
it
actually
doesn't
tell
you
very
much.
It
tells
you
what
commit
you're
on
its
message
and
if
you're
lucky
and
your
page
is
long
enough,
you
can
see
the
commits
after
it.
A
It
doesn't
tell
you
what
branch
you're
on
it
doesn't
tell
you
where
your
other
branches
are.
If
you
work
at
a
company
like
Facebook
with
thousands
of
engineers
committing
you
see
your
commit
and
then
thousands
of
people
you
don't
care
about,
and
so
we
found
people
using
logs
just
did
not
have
a
good
grasp
of
the
repository.
A
So
to
remedy
this,
we
introduced
something
called
smart
log,
and
this
one
has
a
lot
of
click,
so
I'm
going
to
stand
over
here,
but
basically
it's
a
much
more
information,
dense,
more
readable
user
experience
to
understanding
your
repository.
It
shows
you
things
like
where
you're
working
copy
is
right.
Now,
that's
that
purple
line.
It
shows
you
where
your
other
branches
are
here's,
my
branch
and
it's
over
there.
It
shows
you
where
the
remote
branches
are
so
master,
it's
right
there.
A
It
does
this
cool
thing
where
it
hides
all
the
commits
you
don't
care
about
that
little
dot,
dot
dot
in
the
corner.
That's
it
alighting
thousands
of
commits
from
users
so
that
you
can
see
the
structure
of
your
repository
without
all
the
crust.
It
shows
you
things
like
metadata
about
the
commits
those
d--
numbers.
Those
are
code
review
identifiers.
So
now,
from
this
diagram,
you
can
easily
you
can
even
click
on
them
in
certain
terminals
and
it
will
take
you
to
the
code
review.
A
It
shows
you
the
difference
between
your
local
commits
and
the
server
commits
the
bright,
yellow,
bold,
that
is
a
local,
commit
the
kind
of
darker
yellow
sin.
It's
a
little
subtle,
but
that's
the
server's
commits,
and
so
in
this
one
UI.
You
can
start
to
see
all
these
different
pieces
of
information
really
intuitively.
It
shows
you,
where
commits.
Are
that
don't
have
bookmarks
branches,
for
instance,
and
get
if
you
delete
a
branch?
You
have
to
then
understand
the
rest
log
god
help
you
to
recover
that
commit
here.
A
It's
right
there
there's
the
hash,
put
a
bookmark
on
it.
You're
done
you
don't
even
need
a
bookmark,
that's
kind
of
a
mercurial
feature,
but
like
this
ability
to
recover
easily
is
what
we're
going
for
and
it's
lasted.
This
is
my
favorite
bit
this
little
X
with
the
grey
words
next
to
it.
That
is
us
starting
to
show
users
how
their
repository
has
changed
over
time.
In
this
case
it
says,
pushed
as
bla.
A
That
means
that
local
commit
has
already
been
pushed
to
master
and
that's
the
hash
so
I
know
from
seeing
this
that
I
need
to
take
that
top
commit
off
and
rebase
it
onto
master,
and
so
now
we're
starting
to
explain
how
their
repository
has
evolved
over
time
in
a
very
intuitive
way,
and
this
UI
is
the
single
most
important
UI
at
Facebook
for
source
control.
It
is
like
I
teach
boot.
Campers
boot
campers
are
new
engineers
at
Facebook,
I
teach
them
and
I
teach
them.
A
A
I
have
someone
cuts
me
and
say:
smart
log
maybe
understand
what
it's
just
a
dag
means,
so
smart
log
is
explaining
it
to
them
and
they
go
back
to
the
get
community
smarter
for
it
and
now
I
know
get
can
produce
this
kind
of
UI.
If
you
know
the
incantation,
but
the
critical
thing
here
is
not
that
it
can
be
done.
It's
that
it
becomes
the
default
view
on
their
source
control
environment.
A
So
that's
kind
of
about
understanding.
The
repository
there's,
also
problems
with
editing
repositories
and
stack.
Commit
workflows
in
particular.
Have
a
lot
of
trouble.
I
had
a
new
engineer.
Come
at
me
once
he
said:
I
have
my
repo
I
need
help
I'm
like
I
got
this
like
I'm
paid
to
fix
repositories,
and
so
he
runs
a
smart
log
and
it's
like
45
commits
long
and
there's
branching
and
merging
and
forking,
and
things
going
down.
I'm
like
how
is
that
even
possible?
A
Nothing
goes
down
and
I
looked
at
it
like
you
know
what
god
help
you,
because
I'm
out
I
can't
do
this
and
so
stack
workflows
and
get
and
in
normal
mercurial.
Today,
look
a
lot
like
this.
You
run
rebase
si
and
first
of
all,
why
am
I
running
rebase
when
I
want
to
edit
my
stack
of
commits,
like
as
a
user
experience?
That's
that's
a
little
weird
at
the
developer,
I
understand,
but
it's
not
a
great
UI,
but
then
let's
say
I
want
to
edit
commit
V.
I
go
I
change
it
to
edit
I.
A
In
turn
to
this
very
stateful
thing
where
I
have
to
remember
to
do
my
work
and
then
continue,
it's
just
not
an
intuitive
flow,
and
so
we've
done
a
lot
of
things
to
help
the
stacked
workflow
for
people.
I
want
to
talk
about
one,
because
it's
just
it's
really
freaking
cool,
it's
called
hg
absorb
and
basically
it
allows
you
to
have
a
stack
of
commits.
You
can
have
some
pending
changes
at
the
top
and
it
will
detect
where
each
part
of
your
pending
changes.
A
It
belongs
in
the
stack
and
then
automatically
perform
the
amend
for
you
into
all
the
right
locations
without
any
conflicts.
If
there's
a
chance
of
conflict,
it
will
leave
its
ending,
but
everything
else
gets
amended
trivially.
So
here's
an
example
Oh
Illustrated
for
you.
So
this
is
my
before
state
I
have
three
commits
I
introduced
a
main
I
had
a
print
hello.
I
had
a
standard
library
include-
and
this
is
my
pending
change.
I
have
another
standard
library,
I
changed
hello
to
world
and
I
replace
0
with
success
and
get
if
I
wanted
to
perform.
A
This
amend
to
all
the
right
places.
I'd
have
to
do
something
like
this,
where
I
get
commit
P,
so
I
pick
one
chunk:
I
have
to
get
P
or
get
commit
P
with
an
edit
to
split
that
two
lines
apart
and
then,
after
all
of
that,
I
have
to
do
a
rebase,
I
reorder
things
change
it
to
sticks
up
and
pray
that
there's
no
conflicts
along
the
way.
So
this
is
a
very
understandable
thing.
A
A
user
wants
to
do
with
a
very
convoluted
way
of
doing
it,
and
so
with
absorb
they
can
literally
just
type
H
to
absorb
and
it
just
works
in
this
case,
the
top
line
it
figured
out
that
the
standard
library
probably
belongs
in
that
top
commit.
So
that's.
Where
puts
it?
It
figures
out
that
print
s,
hello
was
in
the
second
commit,
so
let's
put
world
in
that
one
and
it
figures
out
that
the
return
zero
became
returns
test
success,
so
it
puts
it
in
the
first
commit,
and
so
it
really.
A
This
is
the
type
of
UI
that
we
need
to
be
inventing
for
our
users,
ones
that
like
match
their
intent
and
do
it
to
the
best
availability
without
making
the
user
understand
what
all
they
have
to
do,
and
it's
a
little
bit
magic,
but
it's
magic
in
a
very
clean
way
and
so
I
think
a
lot
of
user
experience
could
benefit
from
this
approach
and
that's
just
the
tip
of
the
iceberg.
We've
introduced
a
whole
bunch
of
commands
that
I
can't
get
into,
but
that
helped
the
user
experience
HD
fold.
Hd
split.
A
Lets
you
fold
and
split:
commit
like
no
more
using
git
rebase
squash,
blah
I,
don't
even
know
how
you
split
a
commit
and
get
I
guess
edit
and
reset
or
something
but
that's
hard
for
a
user,
and
this
is
trivial
and
memorable.
If
you
want
to
edit
a
commit
in
the
middle
of
a
stack
instead
of
like
using
git
rebase
si,
you
can
just
check
out
the
frickin
commit
and
run
amend
and
it
just
works,
and
once
you've
messed
up
the
middle
of
your
stack
of
it,
we
have
this
command
called
restock.
A
That
brings
it
all
back
together,
so
this
is
about
creating
you
eyes
that
are
much
more
intuitive,
and
that
applies
to
recovery
as
well.
Santiago
earlier
I
think
I
think
that's
the
same.
Hopefully
that
talked
about
ways
in
which
we
can
prove
the
UI
talked
about
recovering.
So
if
you
want
to
undo
in
a
minute
or
undo
parts
of
a
commit
in
mercurial,
you
just
run
on
a
mint
and
uncommit.
Now
you
don't
have
to
understand
a
ref
log.
You
don't
have
to
get
a
PhD
to
understand
reset
anymore.
A
It
just
works
and
it
makes
it
gives
users
confidence
that
they
can
recover
from
mistakes.
And
that's
one
of
the
most
important
things
we
can
do
is
provide
user
experiences
that
gives
them
confidence
in
what
they're
doing
and
so
there's
a
whole
lot
more
and
I'd
be
happy
to
talk
with
other
people
about
this,
but
that's
just
what
I
want
to
highlight
here.
So
the
last
two
things
I
talked
about
we're
user
experience.
This
one
here
is
about
kind
of
organizational
experience.
A
Sparse
checkouts
exist
in
both
git
and
mercurial,
and
if
you,
google,
how
do
I
use
a
sparse,
checkout
and
get?
This
is
the
first
page
and
first
of
all,
all
right,
you're
editing
some
weird
file,
and
then
you
run
get
read
tree
new
head.
What
I
work
on
source
control
and
I
haven't
figured
that
one
out
yet,
but
the
worst
part
of
this
is
more
subtle.
A
Is
that
if
you
want
to
use
this
at
an
organizational
level,
you
have
to
have
all
of
your
users
run
this
and
then,
if
one
guy
over
here
adds
a
build
dependency,
all
the
users
have
to
edit
their
file
again
and
run,
get
retreating
you
head
and
that's
just
not
going
to
scale
unless
you
put
a
lot
of
tooling
on
top
of
it.
So
that's
the
part
that
prevents
us
from
using
this
kind
of
functionality
at
an
organization.
So
in
murkrow
we
invented
this
concept.
A
We're
calling
sparse
profiles
where
it
is
a
sparse
config
that
is
checked
into
the
repository
and
versioned
and
it
changes
over
time
and
it
the
users
working
copy
updates
as
they
commit.
So,
in
this
case,
if
they
have
the
Android
profile
enabled
if
they're
on
commit
a,
they
have
Android
messenger
if
their
own
commit
D,
it
adds
android
common
if
they
go
back
to
a
android
common
disappears
and
so
at
facebook,
an
FB
source
100%
of
people
are
using
sparse
check
out
un
via
these
sparse
profiles
and
only
90%
of
them
even
realize
it.
A
People
are
adding
dependencies
removing
dependencies
and
the
sparse
profiles
are
growing
and
shrinking
and
the
vast
majority
of
users
they
don't
care.
So
one
person's
job
is
to
update
the
dependency,
because
that's
the
person
adding
the
dependency
everyone
else,
zero
effort.
So
it's
kind
of
solved
the
the
organizational
overhead
of
using
sparse
checkout-
and
this
would
be
really
easy-
forget
to
add
I-
mean
not
really
easy.
It's
a
little
complex
but
like
totally
within
reach
that
a
little
UX
and
sparse
becomes
an
actual
feature
that
actual
people
will
use
without
tooling
around
it.
A
You
may
be
wondering
how
do
we
prevent
it
from
getting
out
of
sync?
Someone
has
a
dependency.
They
don't
update
the
profile
that
could
break
it.
Our
test
infrastructure
uses
these
sparse
check
outs.
So
if
you
add
a
dependency-
and
you
don't
tell
the
sparse
profile,
the
tests
fail
and
you're
made
aware,
and
you
can't
push
it
to
the
server.
A
So
this
was
a
kind
of
the
insight
we
needed
to
make
sparse
checkouts
work
at
scale
with
all
of
our
users
and
I
think
it
could
really
benefit
from
this
exact
same
kind
of
technology,
all
right.
The
last
things
we
talked
about
we're
kind
of
user
facing,
but
there's
a
whole
side
of
source
control
that
is
automation
facing,
and
they
have
a
lot
of
demands.
They
need
to
be
able
to
list.
The
repositories.
A
Pail
commits,
see,
contents
run,
blame
run,
blog,
like
automation,
should
be
able
to
use
source
control,
and
the
way
we
did
it
before
is
all
of
the
services
that
needed
to
use
source
control.
They
clone
the
repository
and
they
had
bash
scripts
or
something
that
ran
git,
log
and
HT
log,
and
they
attempted
to
parse
the
results
and
I
can
Dallaire
cases
and
every
single
one
of
you
services
did
that,
and
these
are
not
written
by
like
source
control
experts.
These
are
written
by
like
engineers
who
have
normal
jobs.
A
That
don't
require
understanding
what
gifts
check
out
ex
means
set
a
thing.
I
actually
don't
know,
and
so
this
was
a
huge
pain.
A
these
services
are
extremely
stateful.
You
can't
just
like
take
one
down
and
spin
it
up
somewhere
and
clone
tens
of
gigs,
that's
not
a
short
process
and,
like
I
said
it
has
tons
of
technical
debt
and
all
the
code
where
all
these
people
are
trying
to
handle
inch
cases.
So
to
fix
this
particular
issue,
we
created
a
service
called
SCM
query
and
it's
a
thrift
service.
A
If
you
don't
know
what
thrift
is,
it's
kind
of
a
remote
RPC
system
call
across
networks
very
similar
to
proto
buffers,
but
basically
it's
a
service
that
sits
on
our
git
and
are
mercurial
servers,
because
we
do
have
get
servers,
we
just
don't
use
them
much
and
the
services
that
are
out
there.
If
they
have
a
question
about
source
control,
they
just
ask
the
service
SCM
query
and
it
answers
in
a
type,
safe,
structured
way,
and
so
first
of
all,
this
is
VCS
agnostic.
A
So
now
our
services,
they
don't
care
about
git
and
they
don't
care
about
mercurial.
They
just
care
about
answers,
and
that
has
helped
us
with
our
transition
from
get
to
Mercker
land
from
subversion
to
mercurial.
It
means
we
can
start
to
memcache
results
so
expensive
things
like
blame.
We
don't
have
to
do
it
every
time.
It
means
we
can
redirect
certain
things
to
indices,
so
we're
all
going
to
file
if
you're
repo
is
long
enough.
A
Logging
on
a
file
takes
a
long
time,
so
we
built
an
index
for
that
and
now
it's
instant
it
lets
you
do
things
like
now.
All
of
these
services
are
stateless.
We've
deleted
tens
of
gigabytes
from
them
and
now
they're
lightweight.
They
can
spin
up
quickly
fail
over
quickly
and
the
whole
world's
a
little
nicer,
and
my
favorite
part
is
that
we
replace
all
that
crappy
bash
code
with
just
type
safe
thrift.
A
A
I
actually
just
talked
to
Syed
the
Microsoft
guy,
who
talked
to
you
in
the
conference
room
back
there
and
we're
going
to
have
like
coffee
next
week
or
something
because
it's
going
to
be
really
cool
kind
of
seeing
these
two
things
move
together
like
that
on
the
user
experience
tonight,
we
as
a
source
control
community
need
to
do
a
better
job
of
building
you
eyes
that
are
accessible,
intuitive
and
enable
novice
users
to
be
power.
Users.
A
Everything
I
just
talked
about
is
how
we
are
trying
to
do
that
for
our
users
in
Facebook,
but
if
the
get
community
could
do
that,
and
the
massive
number
of
good
users
could
take
advantage
of
that,
that
has
the
potential
to
to
redefine
productivity,
for
an
entire
generation
of
users,
and
so
I
think
that's
the
single
most
impactful
thing
it
could
be
doing
right
now
is
producing
an
intuitive
user
experience
that
enables
these
users
to
do
the
cool
things
that
today
only
power
users,
users
can
do
so.
I
just
want
to
leave
you
with
that.
A
Five
minutes:
okay,
the
clock
says:
I
have
five
minutes,
so
we
can
actually
do
questions
and
I
cannot
see
anyone
so
I'm
going
to
get
really
close
up
here.
How
about
there
all
of
it
is
open-source
everything
we've
done
is
open-source.
It
is
not
also
the
questions.
Sorry,
what
why
is
this
not
open
source?
It
is
open
source.
Not
all
of
it
is
in
core
moral,
because
certain
things
break
backwards
compatibility,
but
it's
all
there
for
people
to
use.
In
fact,
some
of
this
other
companies
are
also
using.
A
Why
did
you
not
know
about
this?
Do
you
use
mercurial?
Yes?
Well,
because
it's
it's
complicated.
If
people
start
using
this,
they
break
backwards-compatibility,
it
becomes
harder
for
them
to
get
support
from
upstream
to
get
support
from
stack
overflow,
so
there's
complications
there,
unfortunately
we're
trying
to
get
parts
of
it
into
core
as
well.
Right
now,
though,
in
the
corner,
what
happens
when
push
rebase
introduces
a
test
failure,
then
continuous
tests
catch
it
and
we
yell
at
the
guy
even
as
scale
the
push
rebase
has
been
very,
has
had
very
few
situations
like
that.
A
A
So
do
Facebook
developers
use
git
repository
to
do
feature
development
and
the
answer
is
generally
no
90%
use
mercurial
directly,
there's
some
small
repost
like
we
have
oculus
there
there.
You
know
they
were
an
acquisition,
they
have
different
needs,
they
use
git
in
some
cases
or
other
things,
but
though
the
vast
vast
majority
use
mercurial.
A
So
the
fact
that
we're
doing
all
these
merges
and
stuff
on
the
server
does
that
not
cause
problems.
So
one
thing
like
I
said:
is:
it
will
not
do
a
textual
merge
at
all?
So
if
someone
else
has
touched
the
file
you
touched,
it
will
not
perform
the
rebase
for
you
now
it's
possible
that
there
introduces
a
bill
break
by
two
people
committing
at
the
same
time
to
different
files.
Generally,
it's
not
a
problem
like
anyway.