►
Description
Is your Git repository a pain to work with because every operation takes ages? In this Workshop, you'll learn why Git repositories become slow, how you can fix your own repository, and how you avoid new repository trouble in the future. Difficulty level = Advanced (300)
For more from GitHub Universe 2020, visit https://githubuniverse.com
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
B
B
B
A
A
B
D
D
There
are
a
few
things
that
we
asked
for
you
to
have
ready
for
today's
workshop.
Hopefully
you
were
able
to
do
those
that
included
a
clone
or
a
fork
of
a
repository
you'd
like
to
reduce
in
size
the
time
it
took
to
clone
the
repository,
because
we'll
need
that
later,
some
installation
of
get
lfs
get
sizer,
get
filter,
repo
and
then
also
a
clone
or
a
copy
of
the
workshop
repository
as
there's
some
tools
in
there
as
well.
D
We're
going
to
start
today
by
going
over
history
which
will
dive
into
what
makes
up
a
commit
how
those
commits
can
be
contributors
to
the
bloat
of
repository,
we'll
also
be
covering
ways
to
prevent
this
repository
bloat
and
how
you
can
remediate
it
if
you're
already
experiencing
it
now
most
of
us
know
or
have
a
pretty
good
idea
of
how
git
works.
However,
I
wanted
to
take
a
quick
refresher
on
what
comprises
a
commit
and
how
commits
contribute
to
the
history
within
a
repository
commit
has
seven
major
pieces.
D
The
commit
message
is
a
short
description
of
the
changes
that
are
being
made
and
is
saved
at
the
time
of
the
commit
action
with
the
change
set.
Commit
message
is
comprised
of
two
parts,
the
subject
line,
which
is
limited
to
50
characters
and
the
pattern.
The
pattern
of
this
subject
line
usually
completes
the
sentence.
This
change
set.
Will
the
body
is
not
always
utilized,
but
it
can
contain
pertinent
information
around
the
change
set,
including
some
release
notes
information.
D
D
D
D
And
lastly,
we
have
a
parent.
A
commit
object
may
have
multiple
parents,
one
parent
indicates
an
ordinary
commit
more
than
one
parent
indicates
a
commit
that
is
emerged
between
several
lines
of
history.
Initial
commits
have
no
parents
now.
Please
remember
that
last
line,
because
it
will
become
important
later
in
the
session
that
initial
commits
have
no
parents.
D
D
D
D
D
D
D
Github
manages
this
former
file
in
the
repository
when
you
clone
the
repository
down
to
your
local
machine.
Github
uses
the
pointer
file
as
a
map
to
go
and
find
that
large
file
for
you.
By
doing
this,
it's
not
loading
your
repository
with
multiple
versions
of
an
already
large
file
inside
the
repository
itself.
D
You
can
also
do
some
cleanup
of
files
in
your
existing
repository
by
moving
large
files
into
git
lfs.
We
do
have
documentation
with
steps
on
how
to
do
this,
that
we
can
provide
you
later
on.
If
you
are
interested,
however,
I
do
want
you
to
be
careful
because
git
lfs
can
break
some
automations
and
it
can't
be
used
cannot
be
used
with
github
pages.
D
D
There
is
also
a
way
to
connect
your
newly
grafted
repository
locally
to
the
history
of
the
past,
so
that
you
can
have
that
history.
If
you
need
it,
we
will
be
getting
more
into
grafting
later
on.
However,
I
wanted
to
highlight
that
grafting,
along
with
git
lfs,
binary,
artifact
storage,
dependency
managers
and
all
the
other
tools
available
available
to
us
are
all
ways
of
managing
your
model.
Your
mono
repository.
D
D
We
want
you
to
kind
of
go
through
some
of
those
on
your
own
repository
now,
if
you
have,
if
you
go
to
the
activity,
one
issue
in
the
workshop
repository
you'll
find
the
commands
that
are
run
on
the
linux
kernel.
Please
run
those
on
some
of
the
files
in
your
repository
and
also
your
repository
itself
and
report.
D
B
B
B
B
A
B
B
B
B
B
D
D
D
D
C
Thanks
it
for
the
really
nice
introduction
onto
the
git
history,
so
let's
just
have
a
look
to
the
analysis,
so
you've
talked
about
the
history,
but
at
the
end
the
whole
thing
of
the
history
is
that
it's
kind
of
like
immutable.
Of
course
you
can
change
it,
but
the
history
remains.
So
what
you
add
in
the
history
remains
in
the
git
history
and
that's
good,
but
also
you
may
find
that
it
has
some
things
that
you
need
to
realize
when
you
are
putting
things
into
git.
C
So
when
we
say
it
may
be
a
problem,
what
we
are
thinking
so
actually
the
reasons
why
your
history
may
become
big
can
be
two
mainly
the
first
one
is
that
your
repository
is
actually
big.
It
has
a
lot
of
history
like
it
happens,
for
example
with
the
linux
repository
or
it
may
be
that
you
are
storing
things
that
you
shouldn't
be
storing
in
the
head
of
your
history.
C
Also,
your
ci
cd
clones
may
be
begin,
become
slow
just
because
you're
cloning,
it.
Of
course
you
can
improve
it
just
with
doing
a
a
a
shallow
clone
just
for
the
the
first
commit
that
is
done
in
the
repository.
But
still
you
may
have
a
problem
if
you
want
to
do
the
whole
clone
and
it
will
be
slower
and
finally,
just
working
with
this
kind
of
repositories
becomes
harder
and
harder
with
the
time
passing.
C
Just
an
example
of
this
ux
experience.
We
just
tried
to
do
a
full
clone
of
the
linux
repository
and
in
a
machine
that
actually
has
a
good
ram
and
good
cpu
and
also
a
big
network
connection.
It
took
around
11
minutes,
so
imagine
11
minutes
multiplied
for
all
the
people
that
actually
have
to
clone
the
linux
repository
as
well
as
any
other
repository.
It's
a
lot
of
time
and
it's
summing
it
up.
C
Additionally,
let's
talk
about
the
cpu
part,
so
this
is
an
example
of
a
cpu
graph
for
a
for
an
instance
of
github
enterprise
that
actually
had
many
many
repositories
over
one
gigabyte.
Even
one
of
those
was
over
five
gigabytes,
and
this
actually
is
a
really
bad
graph,
because
it's
reaching
the
100
cpu
multiple
times,
and
this
means
that
you
may
get
some
unicorns
in
your
instance.
C
Additional
to
that
we
have
the
platform
samples
repository
where
there
are
three
different
scripts
that
you
can
run
in
your
repository,
and
each
of
them
will
give
you
some
insights
on
how
the
repository
is.
The
first
one
is
about
lfs
and
basically
it
allows
you
to
find
files
that,
by
the
extension
should
be
in
lfs
like,
for
example,
mp3
or
mob
files.
All
these
kind
of
files
should
be
in
lfs
and
not
just
directly
into
your
repo
find
a
git
find
dears.
C
It
gives
you
a
lot
of
analysis
for
your
repository
with
different
files
and
each
of
those
some
of
them
are
also
related
to
the
previous
scripts,
and
some
of
them
will
be
new,
but
it's
good
to
just
run
in
your
repository
and
understand
better
how
all
the
size
is
being
summed
up
when
you
are
using
it
so
talking,
first
of
a
git
sizer
and
we'll
just
run
all
these
scripts
into
the
linux
kernel.
So
you
understand
better
how
it
looks
like,
and
actually
I'm
gonna
just
give
you
a
spoiler.
C
The
linux
kernel
is
actually
a
really
good
repo,
even
though
it's
big
and
it's
big
because
of
his
history.
So
in
this
case
we
just
run
the
git
sizer
and
we
can
see
that
in
the
number
of
blobs
is
on
the
millions
number
and
same
for
the
trees.
So
if
we
analyze
the
space
that
is
taken,
let's
just
go
to
the
next
slide,
and
we
see
that
this
space
is
actually
quite
a
lot.
C
It's
adding
up
with
the
whole
time
of
the
history
up
to
12.8
gigabytes,
just
in
trees
and
remember
the
trees
is
the
divs
between
the
different
modifications
on
your
on
your
files
during
the
different
commits
that
you're,
adding
blobs
are
the
actual
files
and
it's
adding
up
to
the
77
gigabytes
and
something
that
is
interesting.
And
that's
why
I
say
you:
you
should
run
these
scripts
into
your
repository,
but
because
it
will
give
you
some
interesting
insights.
C
The
the
interesting
part
here
is
the
level
of
concern,
and
there
we
can
see
the
different
stars,
and
this
is
giving
us.
What
is
the
level
of
concern
that
this
specific
line
has
on
your
repository
and
just
looking
at
that?
We
can
see
some
brackets
with
numbers
like
at
the
bottom.
It
says
maximum
parents
and
it
says
66,
that's
actually
really
strange
right.
That's
not
something
you
that
you're
expected
to
find
on
your
repository.
C
So
let's
just
go
there
analyze
and
see
what
exactly
happened
and
just
at
the
end
of
this
script,
we
can
see
these
numbers
with
the
brackets
and
the
shafts
that
they
are
they
have
and
where,
where
these
kind
of
events
happen.
We
also
have
here
some
statistics,
but
they
are
not
really
relevant
for
the
rest
of
the
thing.
So,
let's
just
see
that
66
points
that
happened
on
their
linux
kernel
and
there
you
go.
We
can
do
git
show
with
the
hash
that
we
the
shot
that
we
see
there,
and
actually
we
see
here
a.
E
C
Okay,
so
if
we
go
to
the
second
script,
let's
just
run
the
git
find
lfs
extensions.
If
you
run
this
in
your
repository,
the
kind
of
statistics
that
you
will
get
is
the
types
of
files
that
your
repository
is
having
and
they
are
ordered
by
extension.
So
if
you
look
at
this,
actually
it
looks
pretty
well,
because
you
see
that
there
is
mainly
text
and
that's
what
we
expect
in
a
repository
just
text
as
much
as
possible.
C
If
you
see
something
like
binaries,
it's
not
as
good
and
if
we
analyze
the
rest
of
the
lines
to
understand
the
output
of
this
of
this
script,
we
will
see
the
l-share
basically
tells
you
the
percentage
of
things
that
you
should
probably
move
to
lfs.
In
this
case,
it's
mainly
text
not
much
that
we
can
move
into
lfs
and
then
there
is
also
the
count
which
tells
you
the
amount
of
files
that
you
should
put
into
the
lfs
and
finally,
the
size
that
these
files
are
summing
it
up
all
together.
C
So
it's
also
a
good
way
to
see
with
which
kind
of
extensions
are
taking
space
on
your
repo
and
as
an
example,
we
have
now
a
repository
that
is
not
so
good,
as
it
happens
with
the
linux
kernel,
and
here
we
see
that
we
actually
have
some
zip
files
like
gsat
is
the
extension
and
it
says
binary,
and
if
we
look
at
the
elsewhere,
it
says
yes
move
everything
into
lfs.
We
have
only
two
files
and
from
those
two
files
we
have
143.
C
C
Basically
it
will
tell
you
the
amount
of
files
that
are
in
each
of
the
folders.
This
is
order
from
the
maximum
to
the
minimum,
and
usually
the
most
interesting
part
is
at
the
top
of
the
screen.
So
even
just
doing
the
head
nine.
With
with
the
minus
n
and
20,
you
will
see
enough
results
that
are
interesting
and
well
here
we
see
that
the
drivers
folder
is
actually
the
biggest
one
in
the
linux
kernel.
C
Again,
that's
fine,
that's
expected,
because
we
are
expecting
to
have
a
lot
of
files
for
the
drivers
and
probably
they
should
be
in
the
repository.
They
are
just
text
files
of
headers
of
c,
so
it
is
what
it
is,
but
we
can
check
other
repositories
like
this
one
and
actually,
if
we
just
look
into
the
first
elements
well,
it
says
no
modules
if
you're
familiar
with
javascript,
no
modules
is
where
you
store
your
dependencies.
So
someone
did
something
really
weird
with
this
repository,
pushing
their
dependencies
that
he
downloaded
instead
of
putting
them
into
git
ignore.
C
C
That
may
be
interesting,
like
x86
lib
tools,
those
somewhat
used
to
have
files
or
folders
that
usually
shouldn't
be
committed
to
get,
and
they
usually
have
even
binaries
that
are
compiled,
so
just
have
a
look
and
make
sure
that
you
don't
see
something
that
cuts
your
eye
in
this
script.
In
this
case,
we
run
it
in
the
linux
kernel
and
again,
some
of
those
folders
usually
in
your
repositories,
might
not
be
good,
but
here
tools
lib
arc.
C
All
of
those
are
okay,
because
it's
a
kernel,
let's
just
have
a
look
to
something
that
is
not
so
good,
and
in
this
case
another
repository
has
some
scripts
that
may
catch
your
app
like
scripts
utils
that
you
get
ben.
I
am
not
saying
that
this
necessarily
shouldn't
be
in
the
repository,
but
hey
just
have
a
look.
If
it's
in
the
repository,
it
should
be
just
remove
it,
and
finally,
we
have
also
scripts
backup.
You
may
find
maybe
some
backups
there.
It's
just
something
to
have
a
look.
C
And
finally,
the
last
script
that
we
want
you
to
run
on
the
repository
is
git
filter
repo.
This
will
give
you
a
lot
of
statistics.
If
you
just
run
it,
you
will
see
that
the
analysis
gets
done
and
you
will
find
it
in
the
dot
kit,
filter,
repo,
slash
analysis,
folder.
So
it's
inside
the
repo.
When
you
run
it,
it
may
take
a
little
bit
more
time
than
others.
So
just
have
a
look.
C
When
you
run
this
script
into
the
repository,
you
will
find
the
following
files.
The
first
one
is
blob,
shas
and
pads,
and
this
will
just
give
you
all
the
different
paths
ordered
by
size
that
are
in
the
repository
and
not
only
the
blocks
and
shafts
that
are
in
the
head,
but
in
the
whole
repository.
So
that's
interesting
to
have
a
look.
Then
directories
all
sizes,
this
one
within
with
the
next
one,
which
is
the
directory
deleted
sizes,
will
give
you
each
directory
and
decide
the
size
it's
taking
in
your
repository
even
for
the
deleted
ones.
C
That's
the
second
folder.
So
why
not?
Just
have
a
look?
Let's
see
if
there
is
any
folder
that
was
committed
once,
but
then
it
got
removed
and
you
did
never
notice
about
it.
So
that's
actually
taking
space
on
your
repository
same
for
the
extensions
all
sizes
it
will
get
for
each
of
the
extensions
the
size
is
taking,
and
it's
not
only
on
the
head,
it's
taking
it
for
the
whole
repository.
So
just
have
a
look.
C
You
may
get
like
something
that
is
changing
quite
a
lot
during
in
the
repository
like,
for
example,
a
log
file.
Imagine
you
have
a
log
file
that
you
are
updating
every
time
a
run
happens,
then
it
will
tell
you
that
the
specific
file
is
not
actually
taking
the
the
size
that
usually,
that
file
takes
like,
for
example,
a
file
taking
a
couple
of
kilobytes,
but
if
you
modify
it
and
again
and
again
and
again
at
the
end,
all
of
this
space
will
be
summed
up
and
maybe
it's
taking
a
couple
of
gigabytes.
C
And
finally,
the
renames
is
not
something
that
you
can
take
a
lot
of
information
from,
but,
for
example,
you
can
find
some
patterns
like
a
log
file
that
is
being
renamed
every
time
you
are
committing
because
of
an
automation
or
something
like
that.
If
you
see
something
that
is
a
pattern
that
shouldn't
be
in
a
repository
just
make
sure
make
sure
you
investigate
it.
C
And
finally,
I
want
to
give
you
a
couple
of
customer
examples
that
we've
seen
during
our
engagements,
so
one
customer
basically
was
storing
some
emoji
box
that
was
adding
up
to
one
gigabyte.
I
know
what
it
wasn't
used
at
all,
so
this
kind
of
scripts
help
them
to
understand
what
was
happening
on
the
repository
and
why
they
had
that
extra
gigabyte
happening
in
that
repository
another
one,
for
example,
had
some
language
files
that
were
actually
being
modified
quite
a
lot
and
they
had
a
lot
of
entries
because
those
files
were
really
big.
C
The
packing
processes
were
taking
a
lot
and
taking
a
lot
of
cpu
from
their
machines,
so
splitting
it
or
modifying
the
ways
the
the
languages
were
handled
to
the
application
just
fixed
the
issue.
Then
another
customer
had
some
author
generated
files
from
local
platforms
that
were
just
committing
those
files
into
the
repository
and
know
what
the
local
platforms
generate.
C
Those
files
automatically-
and
this
is
actually
a
problem
because
each
file
cannot
be
delta
and
compared
and
compressed
into
the
repository
properly,
and
this
is
actually
taking
a
lot
of
cpu
and
probably
a
lot
of
space
making
the
repository
slow.
Another
one
was
just
committing
some
testing
databases
into
the
repository
which,
at
the
end,
the
solution
was
just
to
move
that
testing
database
into
a
dependency
and
an
artifact.
C
C
C
F
F
B
B
B
B
C
Just
a
quick
reminder
when
you
are
running
these
scripts
remember
to
post
the
results
into
these
slack
channels,
so
we
can
have
a
look
to
them
with
you
and
then
make
it
a
little
bit
more
interactive.
That's
a
good
suggestion!
So
you
get
more
insights
from
from
the
running
the
description
to
your
replays.
C
C
C
C
C
C
C
D
B
B
F
F
F
B
D
B
B
B
B
B
B
C
Great,
so
we're
back.
Hopefully
you
got
some
good
insights
from
running
those
commands
and
you
now
have
more
understanding
of
your
repository
and
what
is
actually
taking
a
lot
of
space.
There
keep
just
posting
the
results
that
you
have
gotten
on
on
the
issue
number
two,
and
hopefully
we
can
give
you
some
some
insights
if
we
analyze
those
so
now
that
we
have
analyzed
those,
what
are
the
things
that
actually
are
preventing
for
these
issues.
C
First
of
all,
git
ignore
and
git
attributes
for
git
lfs
are
two
things
that
are
actually
preventing
our
repositories
for
being
so
big,
like
one
gigabyte
size.
Also,
you
can
use
git
submodules
to
make
sure
that
you
just
split
your
repository
into
different
modules.
If
you
don't
want
them
to
sum
it
up
in
all
one
history.
C
Additionally,
to
that
you
can
use
full
request,
reviews
and,
of
course,
pull
request.
Reviews
itself
will
not
save
you
time
or
will
save
you
some
space
in
the
repository,
but
at
the
end,
with
the
reviews,
you
make
sure
that
whatever
you
are
adding
to
your
repository
should
be
there,
because
you
have
another
review
for
someone
else,
and
sometimes
it's
just
a
mistake.
C
One
of
them
is
built
from
our
colleagues
from
professional
services
and
it's
called
lfs
warning
and
it
will
give
you
hands-on
whenever
there
is
a
a
a
file
that
shouldn't
be
in
the
repository,
but
it's
committed
to
it,
then
you
have
also
you
have
to
make
sure
that
your
repository
is
less
than
one
gigabyte,
otherwise
just
analyze
it
and
understand
why
it's
over
it
and
how
you
can
fix
that
and
then
you
can
also
do
a
couple
of
things.
One
is:
restricting
the
objects
object
size
if
you
are
using
github
enterprise
server.
C
You
can
do
that
that
with
progressive
hooks,
but
if
you
are
using
just
github
enterprise
cloud,
something
that
you
can
do
is
run
it
put
a
hook
locally,
so
it
prevents
commit
committing
these
files.
But
sometimes
it's
just
that
your
repository
is
still
big
and
you
can't
do
much
else.
So
we
have
something
that
you
can
do
for
you
and
it's
called
crafting
and
for
that
I'm
handing
over
to
sarah
who
will
talk
about.
D
Crafting
thanks,
avi
mikey,
like
kavi,
said
another
thing
you
can
do
to
help
reduce
the
size
of
your
repository.
If
it
is
already
out
of
hand,
is
crafting,
as
we
covered
in
section
one
graphing
is
taking
your
current
repository,
moving
it
into
a
new
repository
without
the
baggage
and
in
this
image
you
can
see
that
we
have
the
old
repository,
that's
marked
archived,
and
then
we
also
have
the
new
repository
with
the
clean
history.
D
D
There's
several
steps
to
get
to
this
phase,
though
step
one
is
to
actually
clean
your
current
repository
grafting,
your
repository
without
cleaning.
It
is
like
taking
a
dirty
rug,
putting
it
in
your
nice
clean
house
and
that
dirt
actually
still
being
there.
You
actually
need
to
take
that
rug
out,
get
the
dust
out
of
it.
Get
it
cleaned
up
before
you
put
it
in
the
new
house.
D
To
do
this,
you'll
want
to
do
several
things.
One
of
those
is
to
make
sure
that
you
have
large
files
or
binaries
in
the
correct
place.
You
need
to
remove
any
unneeded
or
unwanted
files
like
emojis
log
files
and
those
binaries
that
we
just
talked
about
also
any
kind
of
automated
files
that
aren't
necessarily
necessary
to
be
in
your
repository
need
to
be
removed
or
their
location
changed,
for
where
the
automation
puts
them.
D
Any
dependencies
that
could
be
could
go
into
a
dependency
manager
also
need
to
be
removed.
Example.
That
would
be
an
example
of
this
would
be
the
testing
database
that
needs
to
be
moved
to
dependency
manager
or
artifact
manager,
so
that
it
can
be
called
on
demand,
then
removing
any
independent
components
or
migrating
them
to
get
sub-modules
and
again
those
aren't
things
that
aren't
necessary
to
be
in
your
code.
D
D
D
D
As
for
the
new
repo,
you
could
name
it
to
the
same
name
as
the
original
repo
that
you're
going
to
archive
this
way.
It
doesn't
break
any
of
your
ci
cd
anywhere
that
you've
already
got
it
configured
for
clones
pulls
and
pushes.
The
only
caveat
here
is
that
if
you
have
specified
versions
or
hashes
releases
hard
coded
into
your
automation,
those
will
break
because
when
you
move
to
the
new
repository,
all
of
that
information
is
no
longer
in
the
history.
D
Now
again,
you
want
to
create
this
new
repository
as
soon
as
possible,
but
you
may
not
want
to
make
the
name
fully
until
you're
ready
to
switch
over.
You
could
mark
it
as
new
for
now,
while
you're
doing
some
of
the
cleanup
and
then
when
you're
ready
to
do
switch
over
rename
it
to
the
original
repo
name.
D
D
If
it's
not
merged,
it
won't
be
moved
so
make
sure
all
those
open
pull,
requests
and
open
work
have
been
completed
and
merged
into
the
head
or
the
main
branch
that
you're
wanting
to
move
prior
to
that
change,
and
if,
for
some
reason,
you
start
in
this
process
and
find
that
you're
way
too.
It's
way
too
complicated
or
you
run
into
some
major
problems.
We're
always
here
to
help
you're
more
than
welcome
to
reach
out
to
github
professional
services
for
help.
D
D
Now,
to
do
to
remove
the
history
we're
going
to
do
this
all
on
your
local
machine,
so
you'll
be
able
to
see
this
happening
on
your
local
machine
without
actually
pushing
it
up
until
you're,
ready
and
you're
sure
that
you've
done
everything
right
you're
going
to
do.
The
first
thing
you're
going
to
do
is:
do
a
get
status
to
make
sure
everything
is
there
that
you
want,
and
that
needs
to
be
there.
There
hasn't
been
anything
that
hasn't
been
merged.
D
D
Yes,
you
heard
me
right
you're
going
to
delete
it
you're
going
to
remove
it.
It's
going
to
go
bye-bye
again,
you're
doing
this
locally
you're
not
going
to
commit
this
to
your.
Your
old
repository
is
on
your
local
machine
at
this
point,
once
you've
removed
the
history.
Now
you
need
to
re-initialize
this
as
a
this
folder,
this
repository
as
a
git
repository
with
clean
working
history.
To
do
that,
you're
going
to
do
the
git
event
command,
it's
going
to
replace
that
dot
get
folder,
but
this
time
that
dot
get
folder
is
completely
empty
of
history.
D
Now
all
that
history
is
gone,
you
have
a
clean,
a
clean
repository
that
is
now
streamlined
and
everything's
going
where
it
needs
to
go,
including
your
get
attributes
you
get
ignores
your
lfs
binaries
are
going
where
they
need
to
go.
Log
files
are
going
where
they
need
to
go
you're
ready
to
push
it
up
to
the
new
repository.
D
You'll
need
to
run
a
git
ad
to
add
all
of
the
files
in
that
file
file
structure
into
the
staging
area
for
the
first
commit
once
you've
added
all
the
files.
The
first
commit
message
needs
to
point
to
the
old
repository
so
that
it
does
connect
your
histories
in
a
way
that
you
can
find
them.
If
you
need
to
go
back
for
an
audit
or
anything
like
that,
because
remember,
the
history
is
still
in
your
archive
repository
in
your
remote
next
you're
going
to
push
that
commit
up
to
the
remote
by
doing
this.
D
Now,
optionally,
as
we
stated
earlier,
you
can
connect
the
history
of
the
old
repo
to
the
history
of
your
new
repo
on
your
local
machine.
To
do
this,
you
would
fetch
the
old
repository
back
to
your
local
machine
again,
and
you
would
go.
Do
a
git
log
just
to
make
sure
you
have
the
one
comment
that
you've
previously
had
for
the
new
repo.
D
What
this
will
do
is
connect
the
histories
of
the
two
repositories
on
your
local
machine,
so
that
you
have
it
if
you
need
it
for
some
reason,
however,
I
would
only
suggest
doing
this
if,
for
some
reason
you
do
need
that
history,
if
you
don't
need
it,
it's
always
there.
In
the
archive
repository
on
the
remote,
you
don't
necessarily
have
to
have
it
on
your
local
machine
unless
there
is
a
specific
business
reason,
because
not
only
is
the
old
repository
large
and
cumbersome,
it's
also
probably
several
gigabytes.
D
So
now
we're
going
to
verify
that
you
can
work
in
the
grafted
repo
by
checking
that
your
commits
are
going
to
the
correct
remote
repo
to
do
this,
we're
going
to
simply
do
a
test
commit
with
the
test
file.
You
commit
it
and
check
that
you
can
navigate
to
that
one
that
one
commit
or
that
history
that
is
only
showing
the
one.
D
D
D
D
You
know,
what's
in
the
repositories
that
you
may
want
to
move
or
may
want
to
clean
up
in
activity
three,
we
want
you
to
actually
start
doing
some
of
that
doing
some
of
the
cleanup
and
possibly
doing
a
graph,
a
small
grafting,
we're
going
to
give
you
20
minutes.
We
know
20
minutes
isn't
going
to
get
you
very
far,
but
you
can
probably
at
least
get
a
start
on
it
and
execute
some
of
the
commands
and
see
some
of
the
cleanup
activities
in
action
once
you've
completed
some
of
the
cleanup.
D
We
want
you
to
go
back
and
run
those
analysis
tools
again
and
see
if
you
find
any
improvements
in
your
your
part,
your
repos
that
you're
practicing
on
once
you're
done
we'll
come
back.
If
we
have
time
we
can
discuss
some
of
the
results,
we
will
have
a
period
of
time
at
the
end
for
q.
A
if
you
have
questions,
though,
please
feel
feel
free
to
reach
out
to
us
in
slack
or
in
the
issue,
and
we're
going
to
give
you
20
minutes
with
that
fun.
Elevator.
B
B
B
B
B
B
F
F
F
F
E
E
All
right
folks
to
use
the
time
a
little
bit.
I
would
like
you
if
you,
if
you're
interested,
I
would
like
to
draw
your
attention
towards
our
second
issue
about
the
activity
too,
where
todd
o'connor
posted
quite
interesting
results
there
that
I
think
are
generally
yeah
that
that
are
just
that
apply
to
many
many
repositories
that
we
have
seen
in
at
getup
professional
services
over
the
years.
So
sarah
yeah-
let's,
let's
take
it
a
good
size,
output
first.
E
So
the
first
thing
that
we
that
we
see
here
is
there
is
a
200
megabyte
file
in
the
repository.
That
is
always.
That
is
always
something
to
look,
for
I
mean
200
megabyte
is
a
pretty
big
file.
It's
unlikely
that
is
source
code,
because
you
would
need
to
write
a
lot
into
a
file
and
and
therefore
it
is
usually
a
good
candidate
for
git
lfs
in
general.
E
As
a
rule
of
thumb,
I
would
say
every
file
that
is
larger
than
like
500,
kilobyte
or
maybe
a
megabyte
should
really
be
considered
for
git
lfs,
because
these
files
are
usually
no
source
code
files
as
source
code
files.
Usually
don't
get
so
big
and
and
the
problem
is
that
these
very
large
files-
they
they
don't
come-
sometimes
don't
compress
well
and
and
so
they
basically
make
your
repository
really
big.
So
they
increase
the
size
that
that
you
need
to
increase.
C
E
E
Let's
stop
here
real,
quick,
there's
another
repository
seo
as
you
can,
can
you
go
up
a
little
bit?
That
is,
that
is
another
repository,
but,
as
you
can
see
here,
it's
the
very
same
thing:
it's
a
500
megabyte
file
in
here,
and
that
is
really
the
only
major
concern,
I
would
say,
maybe
90
of
all
the
repositories
that
we
that
we
see
have
the
issue.
There
are
just
a
few
very
large
files
in
there
and
they
are
responsible
for
for
most
of
the
size
of
the
repository
and
usually
these
large
files.
E
Some
sometimes
these
large
files
are
not
even
used
anymore.
They
just
have
been
committed
years
ago
and
and
now
they're
just
carried
around,
and
that
is
actually
what
you
can
fix
with
the
with
the
graft
thing
trick
that
sarah
just
explained.
So,
let's
move
on
to
yeah.
Let's
there
are
some
some
some
get
fs
extensions
output.
So
let's
discuss
this
really
quick.
What
that
actually
means.
E
So
here
we
see
there
are
so.
The
first
line
means
all
the
files
so
or
okay.
If
you
start,
if
you
run
git
lfs
find
git
find
levels
extensions,
it
looks
for
all
the
files
in
your
head
revision
that
are
larger
than
500
kilobyte.
You
can
define
threshold
with
a
parameter
here,
but
the
default
value
is
500
kilobyte.
E
So
four
percent
are
larger
than
500
kilobytes,
so
500
of
them
are
potential
candidates
for
git
lfs
and
the
total
size
of
all
the
files
is
almost
three
more
than
three
gigabyte
and
the
biggest
file
is
149
megabyte.
So
that
is
the
general
overview.
Now,
let's
look
at
the
individual
file
types
and
the
first
one
here
is
dn
files,
so
I
don't
know
what
dn
files
are,
but
100
of
these
files
in
this
repository
are
actually
bigger
than
the
threshold.
E
E
If
you're,
for
instance,
in
in
c
plus
plus
development
header
files,
you
might
have
a
big
project
with,
maybe
maybe
ten
thousand
header
files,
and
it
might
be
that
whatever
two
or
three
header
files
are
really
large.
For
whatever
reason
and
and
this
is
in
that
case
it
would-
it
wouldn't
be
a
good
idea
to
move
these
header
files
to
get
lms
first,
because
that's
really
source
code
and
second
and
git
lfs
works
on
on
file
extensions.
E
So
if
you
move
header
files
to
get
lfs,
then
that
means
all
your
10
000
header
files
would
be
moved
to
lfs
and
not
just
the
one
or
two
that
are
really
large.
So
that's
why
you
want
to
always
look
at
the
percentage
of
files
or
when
you
want
to
always
look
at
a
certain
file
type
and
then
check
what
percentage
of
that
file
type
is
actually
big.
E
So
again,
the
end
files
hundred
percent
of
these
files
are
considered
big,
it's
also
binary,
so
that
is
a
prime
candidate
for
git
lfs,
and
the
same
is
true
for
other
files
here
like,
for
instance,
dll
lib,
so
files.
These
are
all
library
compiled
library
files
and
it's
probably
a
good
idea
to
put
them
in
some
kind
of
dependency
management
system,
depending
on
what
yeah,
what
what
language
or
what
what
programming
language
is
used
here,
a
popular.
E
So
these
are.
This
is
an
option
or,
alternatively,
you
could
also
store
them
and
get
lfs.
If
you
want
to-
and
you
can
see
here,
a
good
percentage
of
these
library
files
are
actually
bigger
than
our
given
threshold.
So
just
to
go
over
this
example.
Here,
dll
files
72
are
larger
and
the
largest
dll
file
is
actually
42
megabyte,
which
is
a
clear
indication
for
for
good
lfs
yeah.
That
is
a
good
lfs
candidate.
E
So
yeah,
let's
move
on
a
little
bit,
so
here
you
stop
for
for
one
second
there.
So
this
this
tool
will
always
will
also
show
text
files.
As
you
can
see
here-
and
here
we
have
the
header
file
that
I
just
talked
about.
So
apparently,
this
project
has
3819
header
files,
and
12
of
them
are
actually
larger
than
500
kilobyte.
E
That
means
zero
percent
like
point
something
percent
of
the
files
are,
are
considered
large.
So
that's
no
good
candidate
fork
for
good
lfs
and
actually
all
these
files,
since
they
are
text
files
text
files
should
always
give
you
a
pause.
I
mean
there
are
some
cases
where
you
want
to
put
text
files
into
lfs,
but
it's
really
really
seldom
all
right.
Then,
let's
move
on.
E
E
Yeah.
Let's
look
at
this
one,
so
there
is
this
file
extension
all
sizes.
That
basically
means
the
the
analysis
tool
looks
at
all
your
png
files
and
at
all
your
dn
files.
So
it
looks
at
all
your
file
extensions
and
tells
you
how
much
space
they
take
up,
and
here
in
twice
repository
we
can
see
png
files
take
up
most
of
the
space
because
they
are
on
the
first
first
line
in
this
result.
So
this
is
a
very
big
number.
E
These
extensions
all
sizes
comes
in
two
flavors
deleted
and
all
so
with
all
we
basically
see
extensions
are
still
present
deleted,
are
extensions
that
are
not
even
available
in
a
hat
revision
anymore,
so
you
carry
them
around,
although
they
they
are
not
used
for
years.
As
you
can
see
here,
they
have
been
deleted,
some
of
them
here
in
in
2016,
they
have
been,
they
have
been
deleted
in
2016,
16
yeah.
So
again,
this
is
a
good.
E
E
D
D
All
right,
so
I
know
like
I
said,
the
20
minutes
is
not
really
a
long
time
for
you
to
be
able
to
get
real
far
down
into
the
cleanup
and
the
grafting
of
your
repository.
But
hopefully
it
gives
you
a
quick
insight
on
how
small
changes
can
make
a
big
difference
and
with
that
I'm
going
to
go
ahead
and
turn
it
over
to
javi
he's
going
to
go
through
some
of
the
things
that
we
realized
with
the
linux
kernel.
C
Yeah
so
before
we
start
with
the
analysis
that
we
did
with
the
linux
kernel,
I
would
like
to
just
do
a
quick
refresh
of
what
the
grafting
at
the
end
did,
and
basically
we
created
a
new
repo.
We
have
still
the
old
rippon.
We
are
connecting
the
histories,
but
at
the
end
we
are
just
taking
whatever
is
in
the
head
of
that
ripple
to
the
new
one.
So,
basically
your
ripple
analysis
will
look
as
it
looks
in
the
head
of
that
ring
of
that
specific
repo.
That's
why
we
say.
C
C
If
that
number
wouldn't
look
as
good
in
terms
of
the
amount
of
data
that
we
are
carrying
over,
then
probably
we
should
clean
up
a
little
bit
more,
as
you
can
see,
happens,
the
same
with
the
trees,
99
percent
of
reduction
and,
of
course,
for
commits
in
the
matching
commits
trees.
It
makes
sense
that
it's
100
reduced
because
at
the
end,
we're
just
cleaning
up
the
history
right
and
keep
in
mind
that
we
run
this
with
the
repository
and
the
grafted
history,
not
not
the
full
history.
C
C
If
we
see
also
the
statistics
on
the
amounts
in
size,
we
see
again
a
big
reduce
in
there.
So
we
see
the
trees
has
been
reduced
by
almost
100.
It's
99
something
same
for
the
blob
size,
it's
98
of
reduction
and
the
commit
size.
Again.
We
are
not
carrying
over
all
the
messages,
but
we're
just
connecting
them
from
the
two
repos.
So
at
the
end,
you
have
all
all
the
good
things
from
both
worlds.
You
have
a
fast
repo
that
is
easy
to
use
and
easy
to
to
maintain.
C
While
you
also
have
the
history
from
the
previous
review
and
if
we
check
one
of
the
main
variables
is
the
cloning
time.
Sorry,
this
is
the
the
time
it
took
to
run
the
git
sizer.
So
first
time
it
was
three
minutes
and
now,
with
the
crafted
repo,
it
was
point
three
seconds.
This
is
a
big
improvement
and,
as
you
can
see,
it
actually
takes
way
less
time
to
process
it
for
the
three
next
scripts
that
we
run,
they
did
find.
C
Lfs
extensions
can
find
many
tiers
and
the
unwanted
deers
the
three
scripts
we
didn't
find
any
kind
of
relevant
improvement,
and
this
is
because,
as
we
told
the
linux
kernel
is
already
a
good
maintained
code
and
they
don't
have
something
that
shouldn't
be
in
the
repo
and
because
of
that,
all
of
those
that
are
meant
to
find
those
those
statistics
that
are
really
bad
for
your
repo.
They
are
not
really
showing
any
kind
of
improvement
because
we
have
improved
the
history.
C
And
finally,
for
the
git
filter,
repo
analyzed,
what
we've
done
is
checking
again
for
the
blobs
commits
and
and
some
of
the
block
sizes
and,
as
you
see
it's
again,
the
same
kind
of
percentage
in
reduction
again,
it
makes
sense
right
because
we
have
just
taken
over
the
whole
history
and
finally,
for
the
script
runtime.
We
see
this
one
took
around
seven
seconds
while
or
eight
seconds,
while
the
first
time
we
run
it,
it
took
18
minutes.
So
it's
actually
a
big
improvement
on
how
you
can
analyze
the
new
repo.
C
So,
first
of
all,
there
is
a
clear
improvement
in
the
operations
speed
with
git
interactions,
and
this
is
just
for
the
analysis
tools,
but
you
can
think
the
same
for
git
clone
get
feds
and
any
other
operations
that
you
run
every
day.
They
will
be
faster
because
they
are
acting
against
a
history
that
is
smaller,
also
just
a
quick
comparison
on
how
much
speed
it
took
on
the
clone.
The
linux
kernel
took
from
11
minutes
to
31
seconds.
C
C
The
size
of
the
history,
of
course
again,
if
you
don't
clean
up
your
repo,
you
will
carry
it
over
and,
yes,
the
beginning
will
be
better,
but
with
the
time
it
will
be
worse
and
worse
and
you
will
have
the
same
problem
and
you
will
have
to
do
grafting
again.
So,
first
of
all
clean
it
up
and
then
move
everything
over
to
the
new
grafted,
repo
and
start
working
them.
And
since
you
have
the
connected
histories,
you
will
be
able
to
still
do
all
the
good
things
that
kid
offers
like
blaming
someone.
C
We
told
that
actually
it's
consuming
a
lot
of
cpu
just
by
having
these
operations
with
big
repositories,
you'll
save
that-
and
maybe
you
can
even
save
some
bucks
just
by
reducing
the
size
of
the
machine
if
you're
hosting
it
yourself.
And
yes,
basically,
this
is
giving
you
a
scalable
process
for
the
future
generations
of
your
code.
D
E
Yeah,
there's
a
there's,
a
question
right
away
from
novalis,
and
the
question
is
given
that
we
now
have
partial
clones
grafting
seems
less
useful
right.
Well,
the
thing
is
so
I
want
to
distinguish
between
two
things,
so
we
have
github
enterprise
server,
that's
our
on-premise
product
and
there
is
getup.com
which
you,
you
know
interact
with
right
now.
E
If
you
look
at
our
repository
and
github.com
has
a
lot
of
servers,
we
have
an
amazing
infrastructure
that
can
pretty
much
handle
any
load,
so
very
huge
repositories
on
gear.com
just
work,
but
on
get
out
of
enterprise
server
you're.
Basically,
you
have
your
own
infrastructure
and
this
own
infrastructure
is
oftentimes
limited
in
the
sense
that
you
cannot.
E
E
That's
a
very
good
question
and
actually
yeah.
We
already
do
that
our
so,
if
you're,
an
enterprise
customer
you
can
there's
like
we,
we
call
it
a
health
check
that
you
can
ask
our
support
engineers
to
do,
and
then
they
will
analyze
yogurt
enterprise
appliance
and
in
that
in
that
task,
usually
they
also
look
at
larger
repositories
yeah.
E
E
So,
just
by
just
looking
at
your
repository,
you
can
only
discover
the
most
obvious
cases
yeah,
so
bottom
line
is
if
you're
interested
and
you
when
you
want
you
want.
If
you
want
your
repository
analyzed,
then
please
reach
out
to
us,
and
then
we
can
schedule
a
professional
services
session,
and
then
we
can
look
at
the
repository
together
and
and
guide
you
through
optimizations.
C
Is
to
have
gates
to
prevent
that
to
happen.
So
at
the
end,
if
you
set
up
your
cicd
tools,
even
with
actions
or
whatever
cicd
pipeline
that
you
have,
you
may
be
able
to
prevent
this
kind
of
things
to
happen
and
the
most
common
one
is
just
committing
things
that
are
not
meant
to
be
in
the
repository,
but
in
lfs.
So
the
action
that
we
showed
before
from
action
desk
lfs
warning
may
help
you
to
to
achieve
that.
And
of
course
you
can
build
your
own
with
the
apis.
D
C
C
Your
head
revision
put
whatever
it
needs
to
be
in
your
lfs
storage
and
whatever
it
needs
to
be
go
to
the
dependency
management
system
or
just
remove
whatever
is
not
used
and
keep
in
mind
that
you
will
just
take
out
all
the
things
that
you
had
in
the
history
from
before.
Like,
for
example,
one
time
you
committed
a
big
file,
but
now
it's
removed
and
you
don't
have
it
in
the
head
history,
that's
fine!
You
will
not
take
that
over,
so
that
will
not
count
on
your
new
grafted
repo.
C
E
Yeah,
maybe
one
one
additional.
So
if
you
do
these
kind
of
operations,
I
highly
recommend
to
check
out
a
tool.
It's
called
that
that
we've
referenced
earlier
to
get
a
repo
filter,
get
re
filter
repo,
which
you
can
use
to
do
all
these
kinds
of
things
like
slicing
and
dicing
repositories,
to
bring
them
into
the
shape
you
want.
C
D
Yeah
and
all
of
the
the
commands
that
we
ran
on
the
linux
kernel
and
and
showed
examples
of
today
are
in
the
readme
in
that
repository
as
well,
and
then
also
the
issues
have
just
basically
a
copy
of
those
commands
that
are
in
the
readme.
So
if
you
have
the
readme
from
the
repository,
you
have
all
the
commands
that
we
ran
by.
D
And,
as
the
sign
says
we'll
be,
we
will
have
the
slight
channel
open
until
the
16th.
So
if
you
do
have
questions
that
come
up
over
the
next
five
days,
when
you're
trying
this
out
do
feel
free
to
jump
in
there,
and
we
can
maybe
give
you
a
few
answers
or
or
clarify
some
things.
If
you
have
questions
so
that
will
be
open
and
available
for
the
next
five
days.
C
E
E
Its
name
is
reject
commits
so
with
this
pre-received
you
can
ensure
that
certain
commits
are
never
pushed
again,
and
this
way
you
can
basically
ensure
that
someone
does
not
accidentally
push
commits
from
the
old
repository
to
the
new
one,
because
that,
as
as
javi
said,
would
increase
the
size
of
the
new
repository
again.
So
this
is
a
very
useful
pre-receive
hook
to
install.
If
you
do
this
kind
of
operation
on
your
kind
of
enterprise
appliance.
C
Yeah,
something
you
can
do
as
well
is
make
sure
so.
Communication
again
is
really
important
for
the
team,
but
if
you
set
up
like
a
setup
script
that
basically
does
the
crafting
for
you
and
you
put
in
your
instructions
to
hey
first
calendar
repo
and
then
run
the
crafting.
Maybe
you
can
add
there
some
some
scripts
to
add,
also
a
pre-commit
hook.
So
you
also
avoid
doing
something
like
that.