►
From YouTube: Making Git for Windows - Git Merge 2018
Description
Presented by Derrick Stolee, Senior Software Engineer, and Johannes Schindelin, Senior Software Engineer, Microsoft
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
So,
thank
you
so
much
for
coming
here.
Thank
you
for
the
opportunity
to
speak.
I
was
introduced.
My
name
is
Johannes
I'm.
Maintaining
good
for
Windows
and
gate
for
Windows
is
actually
a
little
bit
of
a
pun
in
this
title
here
that
making
gate
for
Windows,
because
the
first
half
will
be
what
I
originally
intended
to
get
for.
Windows.
Do
you
mean,
like
gate
for
people
who
work
on
the
windows
planet
so
who
are
who
have
a
Windows
computer,
but
the
second
half
slowly?
A
He
will
be
talking
about
did
for
Windows,
as
in
the
developers
who
developed
Windows,
because
they
are
now
only
good,
so
yeah
I
should
actually
start
out
by
the
credits.
A
couple
of
people
I
would
like
to
thank
one
in
particular.
I
like
would
like
to
point
out.
Johannes
6th
is
the
other
johannes
who
worked
primarily
on
git
for
windows
before
it
became
really
officially
available,
and
he
basically
took
all
the
patches
that
I
had
and
left
unfinished
and
made
made
them
usable.
So
without
him
this
would
not.
This
would
not
happen.
A
A
It
did
not
really
work
on
Windows.
You
have
to
install
something.
That's
called
cygwin
and
cygwin
is
basically
something
that
brings
you
the
functionality
of
linux
to
Windows,
but
it
emulates
things,
so
it's
slow
and
has
problems.
So
that's
why
I
started
to
work
on
this
whole
thing
and
the
first
gate
for
Windows
packaged
and
compiled,
so
that
users
would
not
have
to
build
it
all
themselves.
It
was
actually
done
in
2007,
so
I
completely
missed
the
time,
but
last
year
we
could
have
totally
celebrated
the
10
years.
A
So
let
me
first
describe
a
couple
of
problems
for
the
Windows
platform,
because
many
of
you
probably
do
not
really
suspect,
except
when
listening
to
aids
talk
that
most
of
the
get
development
does
not
actually
happen.
On
Windows
happens
on
Linux
I
actually
claimed
yesterday
on
the
gate
mailing
list
that
all
of
the
core
gift
reviewers
are
on
linux
and
nobody
cares
about
anything
else,
and
somebody
came
back
no
I'm
on
a
Mac.
A
So,
but
that's
where
we
are
most
of
the
corrugated
reviewers
review,
as
we
heard
today,
is
very
important
and
I
totally
agree
review
is
what
makes
your
code
better.
Most
of
them
are
actually
on
Linux.
So
the
first
challenge
to
work
on
git
for
Windows
is
to
make
things
work
on
Windows,
even
if
they're
really
optimized
for
Linux
and
a
couple
of
things
here,
I
would
like
to
point
out,
in
particular
the
scripting
environments.
A
So
git
is
written
in
portable
see
everybody
knows
that
right,
except
for
the
parts
that
are
not
written
in
portable
C,
so
some
are
in
UNIX,
shell,
scripting
and
Windows
users.
Don't
know
UNIX
shell
scripting
because,
as
the
name
says
it's
on
UNIX,
but
now,
if
you
want
to
run
an
interactive
rebase,
the
entry
for
base
is
actually
implemented
as
two
shell
scripts.
If
you
run
a
rebase
as
either
interactive
or
it's
merging
or
it's
the
standard
one
in
total,
there
are
four
UNIX
shell
scripts
involved.
So
how
do
you
execute
that
on
Windows?
A
You
need
a
bash
or
a
UNIX
shell
interpreter
and
that's
a
foreign
thing
for
Windows,
for
example,
if
you
have
a
script
and
you
want
to
mark
it
as
executable
there's
no
such
concept
on
Windows,
you
can't
mark
a
script
executable.
It's
not
exit
files
batch
files,
partial
files,
they
are
executed.
Well,
everything
else
is
a
plain
file.
A
So
these
are
the
challenges
and
of
course,
this
is
one
component
that
gate
for
Windows
has
to
ship
has
to
bundle
in
the
in
in
the
Installer,
and
there
are
many
many
more,
and
so
we
have
something
like
think
of
the
last
number
141
different
components,
making
up
get
for
windows
and
get
is
only
one
of
them.
So
basically,
maintaining
get
for
Windows
is
about
140
times
as
complicated
as
maintaining
get
another,
really
really
fantastic
problem
that
Windows
users
have
our
line
endings.
A
This
comes
from
the
last
times
and
the
last
times
come
actually
from
IBM
IBM
produce
typewriters.
Here
you
packed
on
your
keyboard
and
you
made
a
mistake
and
you
couldn't
really
fix
it,
but
then
next
line
meant
you
took
that
thing
and
you
moved
it
all
the
way
there
and
it
did
two
things
one
was
it
moved
all
the
way
there
so
that
you
were
at
the
first
column
again.
So
that's
that's
a
the
carriage
return
carriage.
Is
this
thing
here.
A
You
probably
don't
even
know
how
typewriters
look
like,
but
anyway,
so
the
next
thing
is.
It
also
moves
that
thing
forward,
so
line
feeds
so
that
you're
at
the
next
line-
and
so
that's
that's.
How
line
endings
look
like
on
Windows
on
UNIX
they're,
just
the
line
feed
they
implicitly
do
a
carriage
returns,
for
sometimes
it
actually
works,
but
the
negative
developers
do
not
care
about
this.
They
always
have
only
one
line,
ending,
say:
yeah.
You
windows
developers,
you
you
care
about
that
and
when
there's
a
problem
in
the
conversion,
yeah
right.
A
So
this
is
the
this
is
one
of
my
favorite
favorite
problems.
Then
another
problem
is
that
everybody
on
linux
assumes
that
everything's
still
every
absolute
path
starts
with
a
slash,
because
that's
what?
What
it
does
there
is
a
unified
filesystem,
even
if
the
devices
are
mapped
into
that,
so
they
share
with
/div
wonderful
on
windows.
It's
not
that
way
and
by
the
way
I
often
hear
that
this
is
POSIX
conversion.
The
thing
on
the
left
side,
but
VMs
is
also
POSIX
and
VMs
paths
look
totally
different.
A
You
would
run
away
screaming
if
you
would
cien,
but
the
get
it
doesn't,
handle
them
and
kid
doesn't
handle
windows
past
very
well
either.
So
we
have
to
deal
with
that
somehow
and
windows.
Also.
We
have
to
deal
quite
often
with
the
spaces
and
file
names,
because
Program
Files
itself
already
has
spaces
and
Windows
2000
documents
and
settings
have
two
spaces
for
the
price
of
one
wonderful
on
Linux.
Nobody
puts
space
into
their
files.
Everybody
knows
better
than
to
do
that
so,
but
we
can't
and
also
another
really
good
point
here
on
the
slide.
A
That
was
not.
My
idea
was
slowly
pointed
out
to
me:
I
thought,
yeah.
Everything
that
you
configure
is
in
Eid
et
Cie
on
Linux.
That
is
the
case
on
Windows.
You
usually
put
that
into
the
registry,
and
so
it
doesn't
have
a
concept
of
registry,
and
so
we
don't
do
that
there
we
use
a
very
foreign
system
when
it
comes
to
Windows
and
to
those
of
you
who
listen
to
AIDS
talk
you've.
Really.
A
We
probably
remember
the
really
horrible
experience
that
you
have
with
cloning
and
checking
out
a
file
and
all
of
a
sudden
you
get.
This
I
can
execute
all
kinds
of
code,
that's
only
because
on
Linux
nobody
thinks
that
anything
is
case
insensitive
and
on
macaws
and
windows.
It
is
case
insensitive,
so
we
still
have
many
problems
there.
They
are
not
solved.
There's
still
a
lot
for
us
to
do,
there's
just
more
pressing
issues
and
not
enough
contributors
taking
care
of
that.
A
A
So
this
is
how
it
looks
like
that's
actually
on
Windows,
because
on
Windows
we
emulate
the
linux
experience
and
get
four
winners
in
the
get
bash,
and
this
is
how
it
can
look
and
that's
much
more
intuitive
to
use.
But
that's
also
another
challenge
on
the
windows.
I
briefly
mentioned
this
problem
with
a
with
the
scripting
environments.
A
So
these
are
problems
also
other
problems
that,
if
ya
Johannes
please
expand
thoughts
I
should
have
probably
expanded,
but
there
are
many
differences
so
on
on
Linux.
What
you
have
is
this
concept
of
you
can
mark
things
as
readable,
writable
and
executable,
and
you
can
do
that
for
the
user,
who
owns
a
file
for
the
group
that
owns
that
file
and
for
everybody
else
on
Windows,
you
have
a
much
more
complicated
thing.
A
You
have
a
CL
to
access
control
list
where
you
can
specify
exactly
who
can
do
what
with
your
files
and
it's
there's
just
no
mapping
but
Linux
assumes
the
Linux
semantics.
So
in
git
repositories
you
have
the
oh
yeah,
it's
executable
or
not
on
Windows.
It
doesn't
make
sense.
So
yeah
I
should
probably
not
even
talk
about
that,
because
I
I
will
only
run
out
of
time.
This
is
another
thing:
that's
that's
showing
you
the
problem
with
the
products
emulation
layer
that
I
mentioned
earlier
when
we
execute
UNIX
shell
scripts.
A
Of
course
there
is
a
emulation
layer
that
makes
it
look
almost
like
we
are
in
Linux,
but
it's
with
flaws
and
these
flaws.
They
hit
users
and
the
user
experience
of
seeing
something
like
fatal
error.
Sig
heap
base.
Mich
mismatch
detected
this
user
experience
is
really
crappy
right,
so
we
managed
over
the
years
to
reduce
this,
but
it's
still
not
gone
yet
so
there
there
are
tons
of
stuff
that
we
still
need
to
do.
A
Maybe
push
more
for
portable
C,
maybe
go
for
alternatives,
so
all
these
are
really
fantastic
problems
that
we
face
in
addition
to
path
packaging.
All
that
complex
system
was
141
packages.
For
this
latter
part.
What
we
use
is
automation,
so
for
the
first
ten
years
of
get
for
one
of
almost
ten
years
of
my
involvement
and
gate.
A
On
top
of
there
and
test
everything
whether
somebody
broke
something
on
Windows,
because,
as
I
said
earlier,
nobody
cares
about
windows
and
get
mailing
lists.
So
when
we
find
breakages
and
can
just
paste
the
error,
then
the
developers
say:
oh
yeah
probably
I
should
do
this
and
that
and
then
we
can
fix
things,
but
that's
all
automated
right
now,
it's
broken
I
need
to
fix
it,
but
once
I
fix
it,
it
works
again
and
then
we
we
don't
have
to
do
that
manually.
So
this
saves
me
about
five
hours
per
day.
A
Another
thing
is
that
we
also
test
our
patches
that
we
want
to
contribute
to
corrugate,
of
course,
but
they're
still
stuck
in
the
gate
for
Windows
Fork.
We
test
this
also
on
Linux
and
Mac
house,
because
we
can,
because
on
bsts
we
have
the
build
agents
to
make
sure
that
we
don't
introduce
something
that
has
the
problem
in
the
other
direction.
Where
people
would
say.
Oh
you
don't
care
about
Linux,
it
doesn't
work
there.
So
that's
something
that
we
do
with
all
of
our
patches
and
then
also
whenever
and
you
get
for.
A
Windows
version
comes
out.
What
we
do
is
hit
a
build
job
saying
so
this
this
current
version,
that's
on
master.
Why
don't
you
make
that?
And
about
one
and
a
half
hours
later,
there
are
all
these
artifacts,
all
the
files
I
test
manually
and
after
that
I
hit
another
button
and
it
automatically
uploads
it
to
github
and
to
nuke
it,
and
it
sends
the
announcement
mail
and
all
this
is
automated.
A
So
this
takes
about
just
for
comparison
to
make
a
release
before
that
automation
took
me
about
two
to
three
days,
including
manual
testing,
and
now
it's
often
done
within
half
a
day,
and
most
of
that
is
just
me
doing
other
things.
Well,
yes,
yes
does
all
the
work
for
me
so
with
this
I
would
like
to
hand
over
just
a
live.
B
Thank
you
and
Thank
You
Johanna,
sorry
for
the
slide
bugs,
if
only
we
were
using
version
control
for
PowerPoint.
Sorry,
there
was
a
right
foot
fault.
He
had
made
two
changes:
I
forgot
to
apply,
but
I'm
gonna
talk
about
the
second
half,
which
is
instead
of
making
gate
for
Windows
we're
talking
about
improving
git
and
specifically
for
the
Windows
operating
system
developers.
But
then
those
benefits
are
going
to
get
to
everybody
on
all
platforms.
B
Last
year
at
git
merge
a
colleague,
Syed
announced
that
Microsoft
was
moving
the
windows
development
team
to
get
using
a
new
tool
called
the
git
virtual
file
system
or
GB
FS,
and
then
later
that
year,
Brian
Harry
announced
that
the
entire
windows
team
had
transitioned
and
that
we
said
mission
accomplished
all
right.
We're
done
no
we're
not
done,
but
we
just
made
sure
that
it
was
possible
and
that
they
can
do
their
work.
They're
not
inhibited,
but
it
could
be
better.
B
The
Windows
repo
is
really
big
and
I
just
wanted.
You
know.
Sometimes
people
say
one
number
like
how
big
a
check
out
is
like
it's
three
and
a
half
million
files.
It's
three
hundred
gigabytes.
If
you
were
to
have
it
on
your
local
disk,
that's
all,
but
gvfs
was
supposed
to
do
by
virtualizing
that
and
not
actually
taking
out
that
much
disk
space,
but
there's
lots
of
other
things
that
make
the
Windows
repository
big
and
comparing
it
to
what's.
Normally
the
big
repo
of
Linux,
the
Linux
kernel.
B
The
few
ones
I
want
to
point
out
is
the
dot
git
slash
index
file
is
a
very
important
file.
It
helps
hold
your
staging
area
and
it's
260
megabytes
in
the
Windows
repo
and
that's
a
huge
hindrance
to
us
being
able
to
do
fast
commands.
Those
are
48
million
objects
in
the
repo
1.7
million
of
them
are
commits,
so
there's
a
lot
of
places
where,
for
an
order
of
magnitude
larger
than
the
Linux
repo,
the
only
one
we're
not
is
how
long
we've
been
around.
B
This
is
only
about
one
year
of
history
and
active
development,
while
the
linux
repo
has
been
around
for
13.
So
that's
a
lot
of
activity
very
fast.
So
why
is
this?
Why
is
it
getting
so
big
so
fast?
Well,
first
off
it
started
out
with
a
very
large
work
directory
right.
The
we
do
have
30
years
of
Windows
development.
That
then,
was
just
a
snapshot
of
the
working
directory,
but
there's
a
lot
of
developer
interaction
every
day,
there's
4,000
engineers
where
this
is
their
job
to
contribute
to
this
repo.
B
That's
that
their
main
job
they're
located
in
three
different
locations
around
the
world,
but
there's
also
a
lot
of
smaller
groups
that
do
some
things.
There's
over
90,000
branches
that
are
actively
used
by
our
developers
and
they're,
pushing
3,000
times
a
day
and
completing
2,300
pull
requests
a
day
and
I'm
counting
weekends.
There,
because
you
know
time
zones
and
stuff.
But
that's
that's
a
lot
of
activity,
lots
of
movement.
B
So
what
we
want
to
do
is
try
to
make
sure
that
all
these
developers
that
are
working
in
this
repo
get
do
their
work
as
efficiently
as
possible
and
get
should
be
out
of
the
way
and
our
number
one
benchmark
for
how
well
we're
doing
that
is
by
measuring
git
status.
Git
status
is
so
important
because
you
really
can't
make
a
commit
safely
without
using
status.
You
need
to
know
what
are
you
going
to
be
committing
and
it
tells
you
where
am
I
in
my
process.
A
lot
of
GUI
tools
are
always
calling
status.
B
Visual
Studio
calls
at
the
S
code,
etc.
So
it's
it's
something
that
is
very
frequently
be
running
in
the
background,
even
if
users
aren't
directly
doing
it,
so
it
might
slow
down
their
machine
if
it's
too
slow
and
then
also
does
it's
a
good
benchmark,
because
it
touches
all
of
the
important
data
it
touches
the
working
directory.
It
does
file
hashing
it's
at
that
dot,
get
slash
index
file
that
we
talked
about
it's
260
megabytes
and
as
we
discovered
it,
also
touches
commit
history,
and
we'll
talk
a
little
bit
more
about
that.
B
When
we
announce
you
invest,
we
said
well
before
gvfs.
This
status
would
take
ten
minutes
to
complete
because
it
would
walk
the
entire
working
directory
of
three
and
a
half
million
files
and
that
it
would
just
be
waiting
for
that
with
G
of
s
GPFS,
we
were
able
to
get
it
down
to
a
typical
five.
Second
time.
That's
not
good
enough
for
us.
We
want
to
get
down
to
less
than
a
second,
because
that
way,
it
feels
more
immediate.
The
developers
aren't
just
saying:
oh
I
type,
a
command
now
I'm
waiting.
B
Oh
now,
it's
done
okay,
so
we
want
to
get
there
and
we're
trying
to
find
out
how
and
we're
working
in
multiple
directions
on
that.
But
this
five
seconds
is
also
only
a
typical
command.
We
were
seeing
that
some
status
calls
were
really
slow,
because
if
it
we,
the
nice
thing
about
having
the
windows
developers
run
and
get,
is
that
they're
a
very
captive
audience?
They
have
to
use
the
tool
to
do
their
job
and
because
the
Windows
development
really
cares
about
whether
or
not
tools
are
getting
in
the
way
of
their
developers
being
efficient.
B
B
That's
great,
but
you
look
at
the
95th
percentile
or
the
99th
percentile
and
you
start
getting
scared,
so
we're
trying
to
figure
out
what's
driving
that
long
tail
and
it
took
us
a
while
to
find
a
repro,
so
here
I
have
the
command
line
for
a
status
from
my
local
box,
my
dev
box,
about
where
I
said:
hey
this
took
over
20
seconds.
Let's
find
out.
Why
and
the
first
thing
that
struck
me
was
actually
there's
nothing
in
the
staging
area.
There's
nothing
untracked!
There's
nothing!
That
I
changed!
B
B
So
we
see
that's
actually
handling
in
this
alias
URL
thing
which
is
actually
outputting
that
line.
So
we
were
saying
yes,
that's
definitely
it,
let's
drill
in
a
little
more.
We
drill
in
really
far
down
in
that
perfu.
When
you
find
out
there's
this
method
called
paint
down
to
common.
It's
very
important
to
the
merge
base
calculation.
Forget
we
see
that
that's
taking
65
percent
of
the
time,
if
you
dig
in
more
you
see,
parse
commit,
is
taking
almost
60
percent.
This
one
method
is
taking
a
long
time.
B
So
let's
say
maybe
there's
a
way
that
we
can
improve,
that
parse
commit
method
and
make
it
faster,
but
parse
commit
seems
like
it's
a
very
well
tracked
method
in
the
get
code
base,
so
that
might
take
a
while.
So
instead
of
doing
something
hard,
let's
do
something
easy
first.
The
first
thing
to
do
is:
let's
get
our
users
on
block.
B
That's
if
they're
in
this
set,
oh
this
mode,
where
they're
very
far
behind
the
remote
branch,
maybe
they
don't
actually
need
that
exact
number
of
a
hundred
thousand
whatever
they
just
need
to
know
that
are
different.
So,
let's
tell
them
hey
it.
Took
you
a
while
to
run
this
computation.
Maybe
you
should
use
this
new
flag
called
no
ahead
behind
and
it
won't
take
so
long
and
so
say:
oh
I
saw
that
message
next
time,
I
run
it
I've
put
in
that
flag,
hey,
look.
It
took
2.1
seconds,
that's
much
better!
That's
that's!
B
I
can
always
override
it
by
saying
ahead
behind
and
it
will
actually
give
me
the
right
number,
but
for
now
we
can
get
them
such
that
they
very
quickly
do
this
and
we
were
able
to
watch
the
telemetry
and
see
there's
a
lot
of
adoption
to
this
so
you're.
Seeing
a
lot
of
people
saying
hey,
this
is
taking
a
while.
B
Let's
start
using
this
notice
that
it's
saying
they
refer
to
different
commits
right,
it's
just
that,
but
I'm
out
of
information
and
that's
enough
for
most
users,
the
one
thing
I
wanna
mention
is
that
you
might
be
thinking
hey
the
windows.
Repo
is
just
incredibly
large.
Why
should
I
care?
This
isn't
gonna
help
me?
Well,
it's
not
just
a
Windows
repo,
especially
when
you're
talking
about
parsing
commits
to
do
a
graph
traversal.
A
lot
of
talks
about
graphs
in
this
session.
I've
been
really
happy
about
that.
B
So,
for
instance,
we
do
get
log
graph
on
the
linux
repo
on
my
Linux
virtual
machine.
It
took
over
seven
seconds.
That's
too
long
to
show
twenty
commits.
It
took
seven
point
seven
seconds
and
that's
because
it's
walking
the
entire
commit
graph
before
it
outputs
a
single
commit.
So
this
is
something
where
yes,
we
real
repos
real
repos
that
normal
people
use
that
are
not
in
this
giant
enormous
refill.
B
They
do
have
these
types
of
issues,
so
I
wouldn't
talk
now
for
three
slides
that
are
gonna,
get
super
technical
and,
if
you
bear
with
me,
I'll
come
back
to
these
nice
pictures
of
command
lines
that
everybody
loves
so
what's
happening
with
the
committe
walk
logic.
Is
that
it's
going
to
call
this
method
called
parse
commit
gently
and
when
it
does,
is
it
passes
a
struct
commit
that
essentially
contains
an
object,
ID
and
says.
B
Please
fill
in
this
struct
commit
with
some
extra
information
and
then
information
is
going
to
be
oh
I'll
get
to
that
a
little
bit,
but
it
passes
that
struck
commit
down
to
the
object
database.
Those
are
your
PAC
files
and
your
loose
objects.
It
searches
through
those
to
see
hey,
do
I,
know
of
that
object.
Yeah
I
found
it
and
then
it
the
opportunity
based
returns,
a
buffer.
B
It
has
to
decompress
that
buffer
and
it
has,
and
then
the
parsed
magenta
has
to
parse
it,
and
it's
essentially
a
plaintext
parse
to
pull
out
this
data,
and
then
it
returns
the
struct
commit
filled
in
with
some
additional
information.
It's
got
the
parents
for
that
commit,
so
you
can
walk
to
its
parents.
It
has
the
route
tree,
so
you
can
find
the
tree
from
that
commit.
It
also
includes
the
commit
date,
which
is
very
helpful
when
you're
doing
certain
date
order
things.
B
So
this
method
is
pulling
all
this
information
out
and
it's
doing
all
this
parsing.
Well,
maybe
if
we
just
said,
let's
not
do
this
plain
text,
parsing
and
decompression
what
let's
just
get
exactly
this
information
that
we
need
and
let's
store
it
in
a
specialized
file.
So
that's
what
we
built
the
serialized
git
commit
graph.
This
is
a
very
special
file
and
it's
got
just
a
four
basic
parts.
B
B
Do
I
know
of
this
commit
hey
I
found
it
it's
in
this
row
of
the
table,
then
you
can
move
to
where
all
that
extra
data
is
just
follow
that
roll
over
to
the
next
table
and
you
can
get
the
tree
ID,
you
can
get
the
date
and
you
can
get
a
couple
parents
out
I'm
going
to
refer
these
parents
using
not
their
object,
IDs,
but
just
an
integer
to
say
hey
if
it's
in
the
graph
look
at
this
row.
So
it's
a
lot
cheaper.
B
It's
only
four
bytes
instead
of
20,
but
you
might
be
thinking
hey.
What
about
octopus
mergers?
There's
more
than
two
parents
in
an
octopus
merge!
Well,
so
the
second
parent
could
also
point
in
to
a
table
of
edge
for
octopus
mergers.
That's
probably
gave
me
very
small.
There's
not
too
many
octopus
merges
out
the
wild,
but
it
does
prevent
that.
B
If
this
struck
commit,
doesn't
have
a
valid
graph
position,
we're
gonna
do
binary,
search
into
that
object,
list
and
say:
hey.
Do
I
find
in
the
graph
great.
Let's
pull
that
data
out
and
since
the
parents
were
referred
to
by
graph
position,
while
those
parents
are
gonna
have
their
graph
position
when
they
get
called
to
parse
and
they
can
navigate
immediately
to
theirs
position
today.
So
you
know
one
look
up
so,
instead
of
having
something
n
log
n,
it
becomes
order
n.
Overall
and
again
we
have
a
fallback.
B
If
it's
not
in
this
graph
file,
let's
just
go
back
to
object.
Id
object
database,
just
the
same
as
normal
and
everything's
gonna
work
out
just
fine,
it's
gonna
be
just
as
slow
as
it
was
before,
but
it'll
work
out.
Are
you
still
with
me
all
right
now?
You
can
get
back
to
this
command
line,
pictures
that
you
all
wanted
so
before
when
they
do
this
get
logged
graph
on
the
Linux
repo.
B
It
took
seven
point
seven
seconds
to
get
these
twenty
commits
and
then
now
takes
one
point
three,
because
of
all
that,
parse
time
it
was
spending
checking
in
these
commits
and
unzipping
unzipping
them
and
parsing
them.
As
plain
text,
hey
now
goes
straight
into
that
structure
pulls
out
that
data
and
it
can
move
on
really
fast.
So
that's
a
that's
a
pretty
big
speed-up
on
a
realistic
data
set.
B
So
let's
take
a
look
at
our
get
status,
I'm
telling
you
that
taking
screenshots
and
I'm
seeing
a
lot
of
variance
in
these
numbers,
so
but
that's
just
how
it
is
sometimes
when
I
run
status
now
and
I
say
just
to
make
sure
I
do
they
head
behind
before
the
graph.
In
this
time
it
took
26
seconds
23.62
that
was
walking
the
graph
as
soon
as
I
put
in
this
graph
and
I
say:
please
use
the
graph
gonna
take
eight
point,
eight
seconds
again,
that's
a
big
jump.
That's
gonna
be
helping
our
users
a
lot.
B
The
important
thing
about
when
you
say
you
have
a
performance
gain,
is
to
not
just
give
up
as
soon
as
you
have
a
gain.
It's
like.
Let's
go
back
and
rerun
our
performance
tracing
and
let's
see
what
else
we
can
do.
What
else
can
we
improve
and
I
pulled
these
screenshots
from
my
/
future
ace
and
I?
Put
them
in
this
slide
and
I
said:
wait
a
minute.
This
doesn't
look
right.
I,
looked
at
this
left-hand
column
and
I
saw
these
three
instances
of
marked
parents
and
interesting
calling
has
object
file.
B
The
whole
point
of
this
graph
was
to
avoid
looking
at
the
object
database.
Why
are
we
calling
this
method
has
object
file
it's
going
to
go
to
the
pack
files
and
loose
objects
turns
out
in
the
merge
code
paint
down
to
common.
It
calls
something
that
does
this,
but
it's
not
in
the
get
logged
code,
so
it
doesn't
doesn't
hit
that
pay,
so
I
knew
so
when
you're
looking
at
the
get
log
as
your
performance
measurement,
it
doesn't
happen,
but
it
does
happen
here.
B
Nice
thing
is,
though,
it's
a
one-line
fix,
that's
already
on
the
mailing
list
and
in
version
to
master
and
with
that
one
line
fix,
we
go
from
eight
point,
eight
to
five
point,
one
seconds
there.
We
are
back
at
our
typical
case,
even
with
walking
these
hundred
thousand
commits.
So
thanks
very
much
for
the
community.
For
all
these.
B
These
comments
on
those
sorts
of
things
on
the
right
hand,
side
I,
do
want
to
point
out
that
there's
another
thing
that
I
was
expecting
to
see
because
I
saw
it
in
an
earlier
perfect
race,
especially
with
the
git
log,
is
that
you
see
I'm
parsing
the
commits
in
the
graph
you
can
see.
Oh
yes,
there
is
some
time
being
spent
parsing
the
commits
in
the
graph,
which
makes
sense
it
can't
go
to
zero,
but
there's
a
thing
where
I'm
filling
the
commit.
B
Where
there's
this
ends,
our
parents
are
died,
which
is
me
looking
at
the
parents
and
making
sure
I
load
them
up,
but
there's
this
other
method
in
there.
That's
taking
six
point.
Seven
percent
of
lookup
tree
right,
I
told
you
that
the
struck
commit
needs
to
have
its
root
tree.
But
what
does
the
root
tree
have
to
do
with
computing,
merge
bases
or
how
far
ahead
out
behind
it?
I'm
we're
loading
these
trees
for
no
reason
so
we're
looking
into
it.
B
We
haven't
figured
out
exactly
how
to
do
it
cleanly
looking
into
making
those
tree
lookups
be
lazy,
so
you'll
only
look
them
up
when
you
really
need
a
tree,
and
that
way
all
of
our
commits
walks
can
stop
looking
up
trees.
Because
again
we
want
we
looked
at
a
hundred
thousand
trees
that
we
never
ever
needed
so
we're.
We
got
that
on
on
the
backlog
to
do
very
soon,
that'll
give
us
more
improvement.
B
Look
into
the
future.
This
get
log
graph
is
my
favorite
command
right,
so
I
love
looking
at
these
pictures
of
graphs
and
here
on
the
Left
II
of
the
command
line.
What
it
looks
like
for
the
Windows
repo
and
here
on
the
right
is
what
it
looks
like
to
do:
a
file
path,
SPECT
graph
history
on
VSDs,
so
you
can
show
the
graph
over
there
on
the
left.
The
command
line
was
taking
nine
point
three
seconds,
and
this
is
after
the
graph
this
you
guys
get
commit
graph.
I
was
talking
about.
B
This
is
with
the
improvements
on
the
right.
It
took
391
milliseconds,
and
that
includes
a
round-trip
to
the
server.
So
what
I
can
tell
you,
because
I
worked
on
this
feature-
is
that
there
are
ways
that
we
can
make
the
command
line
run
as
fast
as
that
we
just
need
to
get
there,
and
the
CEO
has
good
commits
graph
is
step
one
and
we're
gonna
continue
working
on
that
and
continue
working
on
that
until
it's
faster
and
I
also
want
to
point
out
that
again.
Remember
the
git
log
on
graph
for
the
Linux
repository.
B
If
you
at
you
can
do
it
on
a
kernel
folder,
for
instance,
it's
1.8
seconds,
we
can
still
get
that
down
low
too.
So
that's
this
is
where
this
is
like
my
shining
beacon,
if,
where
I
want
to
be
I,
want
to
get
these
git
log
raft
fans
to
be
super
fast,
immediate
for
users
they're
not
waiting
around
to
have
it,
because
this
is
so
useful.
We
can
see
where
merges
happen.