►
From YouTube: Gitaly Training - A tour of Git internals
Description
Karthik Nayak walks through the Git data model.
A
All
right
all
right,
so
let's
go
ahead
and
get
started
so
welcome
everyone
to
Gilly
training
session
two,
so
my
name
is
John
Kai
I'm,
an
engineering
manager
on
giddly,
and
today
we
have
Karthik
Nayak
senior,
backing
engineer
on
giddly
and
he's
going
to
present
on
get
internal.
So
just
a
two
sentence:
intro
like
why
I
think
knowing
the
internal
data
model
of
git
really
helps
to
know
the
tool.
A
Unfortunately,
git
is
one
of
these
tools
that
has
a
super
steep
learning
curve
and
my
experiences
I
didn't
really
fully
understand
what
the
tool
did
until
I
learned
the
internal
data
model
a
little
unfortunate
it
shouldn't.
You
know
tools
shouldn't
be
like
that.
But
you
know
like
git
is
one
of
these
tools.
A
A
There's
a
section
for
questions:
we're
going
to
try
to
do
questions
a
little
differently
and
we're
going
to
try
to
do
it
in
real
time,
so
I'll
kind
of
be
the
moderator,
and
once
we
have
like
a
couple
of
so
go
ahead
and
type
in
your
questions
like
yeah
in
real
time
as
Carthage
is
going
through
his
presentation
and
I'll
stop
him
at
different
points
to
have
him
answer
some
questions
instead
of
waiting
until
the
very
end.
So
that's
one
change
for
blast
time.
So
all
right
so
without
further
Adobe.
Take
it
away.
B
B
B
Repositories,
what
do
they
consists
of
then
we'll
move
on
to
branches
and
tags?
How
do
they
work?
And,
finally,
if
time
permits
will
also
move
into
a
little
bit
about
Pac
files
and
what
they
are
and
how
they
work
before
we
get
started
I'm
going
to
talk
about
something
that
John
kind
of
mentioned,
which
is
the
life
cycle
of
a
git
user.
B
B
B
A
lot
of
these
commands,
which
I
have
used,
and
most
of
us
have
used,
is
more
of
like
something
we
know
cause
and
action,
but
we
don't
know
why
and
that
this
unlocks
a
lot
more
because
of
that
and
also
debugging
becomes
a
lot
easier
like
when
you're
stuck
with
something
and
your
repositories
in
a
state
which
doesn't
seem
normal,
because
you
know
how
it
works
internally.
Debugging
makes
a
lot
more
sense
with
that.
We
will
start
with
the
object
structure
and
get
so
I'm
going
to
start
with
a
simple
repository
here.
B
B
So
in
git
there
are
three
prominent
data
structures.
We
need
structures,
we
need
to
think
about.
One
is
a
comet,
the
other
one
is
a
tree
and
finally,
there's
a
block
so
going
from
bottom
to
top,
a
blob
is
just
a
file
which
contains
data.
We
don't
care
about
the
name
of
the
file,
the
location
of
the
file.
Nothing
is
just
the
data
that
we're
concerned
about
then
comes
the
tree.
Trees
are
more
of
Association
of
how
blobs
can
stay
in
the
repository.
B
So
if
you
have
like
a
directory
and
sub
directory
is
below
that
those
are
represented
by
two
ways
and
then
the
file
name
of
that
blog
will
be
represented
in
the
library.
So
tree
is
overlooking
multiple
blobs
or
multiple
other
trees.
And
finally,
a
commit
just
represents
the
state
of
the
repository
at
a
particular
point
of
time.
So.
B
Confusing
we'll
start
with
a
simple
example,
and
that
should
give
some
clarity
about
what
all
of
these
objects
are.
So
we
start
with
simply
creating
a
file
so
I
create
this
file
say
who,
which
has
contents
data
one
and
then
from
there
we
get
add.
This
is
what
we
do
to
add
the
file
to
staging,
and
finally,
we
commit
that
with
Git
command.
So
now,
if
you
look
at
git,
so
it
shows
that
we
have
this
comment
C1
and
the
data,
and
that
is
data
one
with
the
file
Foo.
B
So
now
what
does
the
comet,
3
and
blob
structure
here
mean?
So
let's
look
at
that.
So
if
you
look
at
the
comment,
it
gives
us
a
Shar
ID
of
that
comment,
which
shows
the
which
is
known
as
the
object
ID
of
that
command.
So
if
you
want
to
see
the
graph
of
this
we
take
this
shy,
ID
and
get
cat
file
is
something
which
allows
us
to
read
these
side.
So
when
I
say,
can
you
tell
me
what
this
object
is?
It
says
this.
B
My
signature
so
and
if
you
see
the
gate,
what
is
the
type
of
this
object?
It
will
tell
us
that
it's
a
comment.
So
if,
when
you
see
it
shows
nothing
but
saying
that
there
is
a
commit-
and
this
is
the
details
of
that
coming
so
now,
if
you
want
to
see
this
tree,
that
this
Comet
refers
to
and
if
I
put
this
there.
So
it's
saying
it's
a
tree
and
if
I
print
that
tree
it
says,
there's
nothing
but
an
object
called
Foo,
which
is
the
name
of
the
file
and.
B
Data,
it
says
data
one
so
to
give
you
an
idea
of
this
is
something
like
this.
So
there's
a
comment
which
has
a
tree
and
the
tree
has
the
data
structure
of
the
block,
which
holds
the
data
data
one
and
the
name
of
that
blob.
The
file
path
of
that
blog,
which
is
full,
is
kept
in
that
way.
I'll
be
sorry.
B
B
B
Want
to
see
this
in
the
data
structure,
so
if
they
see
the
git
and
there's
objects.
This
is
where
it
stores
all
of
these
objects,
blobs,
trees
and
comments.
And
if
you
see
this
data
structure,
you
will
see
that
there
are
three
objects
right
now,
the
first
one
being
the
commit
which
we
printed
2838,
and
you
can
see
that
two
at
three,
eight,
the
second
one
being
the
three
which
is
zero.
B
B
Git
uses
I'm
just
showing
one
of
these
examples,
so
you
can
see
how
it
works,
so
we'll
also
see
how
git
creates
blobs,
for
example.
So
we
know
that
the
Blob
should
contain
this
data.
Foo
and
git.
Has
this
internal
command
called
hash
object
and
I'm?
Saying
hey
git?
If
you
want
to
create
a
blob
with
the
data
full,
can
you
tell
me
what
it
will
be,
and
this
is
what
git
says?
B
C
A
B
B
B
B
That
is
the
name
the
time
of
the
comment:
the
committer
name,
committee,
email
and
the
time
of
like
all
of
those
information
and
which
tree
is
the
comment
created
against.
So
in
our
example.
If
the
tree
would
be
this
one,
which
is
the
one
we
created,
zero,
zero,
sixer
and
it'll
give
us
an
ID.
This
doesn't
match
the
ID
that
we
created
for
this
comment.
That's
only
because
I
didn't
Supply
the
name
the
time
to
be
the
exact
is
the
one
we
just
created.
B
A
B
B
A
B
C
A
B
B
C
B
Let's
say
the
algorithm
takes
in
different
inputs
for
different
objects,
so
we
know
of
three
objects
that
we
spoke
part
one
is
blobs
or
trees
and
commands,
and
for
blob,
like
I
mentioned,
it
only
depends
on
the
data.
So
we
so
here
as
simple
as
this.
So
when
we
have
the
data
it
takes
that
data
and
based
on
the
data
and
the
length
of
that
data,
it
creates
this
hash
object
for
blobs
for
trees.
It
is
the
path
of
that
path
of
a
particular
blob
or
tree.
B
The
idea
of
that
particular
blob
artery,
the
type
which
is
here
in
this
VK
block
and
also
the
permissions.
So
this
is
the
input
and
finally
for
comets,
it's
the
commit
users,
email
time
and
commit
author's
email
time,
and
also
the
three
objects
that
the
Commodore
screen
developments
and
I
believe
also
the
commit
ID
and
the
message
in
the
comment.
So
all
this
information
is
put
together
and
that
you
that
is
sent
to
the
hashing
algorithm,
which
creates
the
hash.
A
B
B
B
B
B
C
B
Didn't
explain
but
cat
file
is
more
of
if
there
is
an
object
in
the
git
data
structure.
Here
the
tree
object
or
any
object
in
the
git
object.
Folder
CAD
file
is
used
to
print
the
contents
of
that
object
in
a
human,
readable
format,
or
also
to
see
what
is
the
type
of
development,
so
Dash
T
would
give
you
the
type.
B
B
In
there,
so
now
this
new
tree
that
new
comment
that
we
created
has
a
parent,
and
this
is
the
tree
Associated
and
we
can
also
cat
file
this
tree
and
you'll
see
now
it
has
two
blocks.
One
is
four
and
one
is
bar,
and
that
makes
sense,
because
now
we
have
two
files
here:
one
is
who-
and
one
is
bar,
whereas.
A
B
No
fire
bar
and
the
good
thing
you
can
see
that
is
that
the
tree
that
we
created
before,
which
is
let
me
just
so
you
can
do
head,
which
is
the
recent,
so
git
draft
Parts
the
ref
pass,
is
used
to
get
the
object
ID.
So
if
I
do
get
get
ref
pass
and
it
shows
the
object
ID
of
head,
which
is
the
same
I'll
get
it's
like
seeing,
did
show
and
you
can
see
the
comment
ID.
So
this
gives
the
object
timing.
B
This
to
say,
get
cat
file,
B
get
wrap
parts
and
which
will
show
us.
The
comment
and
P
visual
shows
the
tree
and
finally,
I
want
to
see
one
comment
before
this,
and
if
you
see
the
tree
of
black
one,
it
only
has
one
file,
whereas
the
new
one
has
two
files,
but
the
cool
part
is
that
the
fool
that
was
created
has
the
same
hash
as
the
food
here.
That
means
for
existing
blobs.
B
B
They're
already
existing
if
there
is
a
blob
with
some
data
and
then
there's
a
new
comment
created
which
uses
that
block,
it
continues
using
the
same
block,
and
that
shows
up
like
this.
So
now
we
can
see
that
we
created
a
new
commit
C2
and
its
parent
is
C1,
and
it
also
has
a
tree
which
has
one
file
bar,
which
has
data
two
and
then
also
Foo,
which
was
previously
created.
So
it
just
links
to
that
older
block
which
is
already
existing.
It
doesn't
create
anything
new.
A
A
C
B
A
B
This
is
and
what
is
it
executable
or
not?
That's
that's
the
kind
of
thing
that
checks
and
like
John
mentioned.
If
we
will
also
see
this
in
future,
when
we
start
creating
subdirectories,
which
are
the
trees,
we
will
see
how
these
changes
for
trees
we're
not
going
into
sub
modules.
But,
yes,
sub
modules
are
also
something
it's.
B
On
to
the
next
question,
why
do
we
have
two
leading
numbers
in
the
directory
structure
here?
This
is
a
good
question
because
now
we're
dealing
with
something
very
small.
This
is
a
small
repository
and
you
can
see
already
with
two
comments
that
we've
come
up
to
like.
There
are
seven
files
in
total.
So
if
you
think
about
something
like
git
lab
repository
or
the
git
repository
the
Linux
repository
there.
B
And
let's
say
git
objects
which
are
being
created,
so
that's
actually
it's
the
file
system
to
some
extent
and
also
increases
the
seek
time
to
get
these
files.
So
this
is
kind
of
a
small
trick
that
git
does,
which
kind
of
provides
some
sort
of
hashing
to
get
your
object.
So
this
gets
you
the
object
directory
and
then
all.
B
C
B
A
B
B
B
And
we
will
commit
it
all
right.
So
now,
let's
look
at
the
same
thing
we
did
at
that
time.
We
will
look
at
the
comment,
so
we
did
this.
It
shows
the
comment
it
says:
there's
a
tree
and
the
parent
does
this:
let's
just
verify
the
pair
and
get
log
one
line,
and
so
this
is
the
comment
that
we
created
and
the
parent
is
this
one
which
makes
sense.
C3
is
the
new
comment.
B
C2
is
this
one
and
if
you
want
to
print
the
information
regarding
the
tree,
this
will
give
us
that
and
if
you
see
now
that
there
is
an
created
here
which
is
B5.
But
if
you
looked
at
the
previous
comment,
which
is
one
behind
C2
is
3,
then
the
four
is
different.
So
while
bar
stays
the
same,
that's
because
the
contents
of
the
file
bar
didn't
change.
The
contents
of
food
changed
so
now,
there's
a
new
object
which
is
created
for
who
and
to
verify
this.
B
B
The
three
structure:
that's
that's
where
we
are
going
back
to
the
diagram.
Now
we
have
C2
which
points
to
C1
and
it
also
and
C3
which
points
to
C2,
and
it
also
has
a
tree
while
it
holds
the
same
link
to
the
blob
bar.
A
new
blog
for
four
was
created,
I'm,
just
putting
the
dash
here
to
show
that
the
new
one
was
created
so
the
same
file
with
different
data.
But
what's
interesting
is
that
blobs
are
stored
as
entire
data,
so
like
it
didn't
store
the
difference
which
is
data
one.
B
A
B
Stores
the
whole
block,
so
if
you
have
a
file
with
100
MB
and
then
you
create
another
file
with
100
MB,
it's
going
to
store
two
of
those.
We
will
talk
about
in
the
future,
how
there
is
mechanisms
for
Delta
vacation
in
git.
But
at
this
point
you
need
to
know
that,
on
the
blob
Storage
level,
the
files
are
stored
with
the
entire
data.
A
A
B
B
Okay,
so
the
going
on
forward
from
here
I
hope
it's
all
clear
till
now,
so
we
will
move
now
to
sub
directories
and
just
show
how
git
handles
now
directories,
because
right
now,
till
whatever
we
saw-
and
all
these
three
structures
we
saw
was
simple
because
all
the
files
are
in
the
root
directory,
so
bar
and
flows
in
the
root
directory.
The
trees
also
show
that
there
are
two
files.
We
don't
care
about.
Subdirectories
and
everything
is
right
here,
but
moving
on
to
subdirectories
and
how
they
work.
So
we
create
a
simple
directory.
B
B
C
B
B
Are
more
of
a
consequence
of
having
files
in
a
structure
but
directories
themselves
do
not
matter
to
git
as
much
now
when
you
add
data
to
a
file
within
that
directory,
things
start
changing.
That's
because
now
there's
a
file
that
git
needs
to
track,
and
now,
if
you
see
it
already
starts
showing
it
in
status,
saying
that
hey
there's
some
new
files
in
this
folder
we
haven't
tracked,
but.
B
B
C
C
B
And
looking
at
the
diagram
now,
so
we
had
three
and
gets
a
little
complicated
with
here,
because
now
we
have
sub
three.
So
C4
is
the
new
comment
that
we
created,
which
has
a
top
level
tree,
which
points
to
one
object,
which
is
the
Foo
and
the
second
object,
which
is
the
bar,
which
were
pre-existing
objects,
but
it
also
created
a
new
sub
treat
which
is
ABC,
which
is
the
file
path
of
that
tree,
and
that
tree
has
a
blob
which
is
Def
with
data.
B
All
right,
this
is
the
final
thing
that
I
wanted
to
cover,
which
is
basically
what
happens
when
files
are
moved.
So
now
that
we
have
ABC
what
happens
if
we
move
it
out,
like,
let's
say
what
happens
to
the
file
inside
ABC
when
we
move
those
this
works.
So
now,
if
you
see
you
get
status,
it
said
the
file
which
was
ABC,
slash,
daf,
got
deleted
it
and
then
there's
a
new
file
that
says
dear.
B
That
the
blob
is
the
same.
The
def
and
the
only
thing
that
changed
was
it
got
removed
from
this
ABC
folder,
which
was
so
it
instead
of
having
a
tree
here
pointing
to
APC.
It
will
should
now
just
put
this
block
directly,
because
that's
what
if
you
look
at
the
structure
now,
there's
ABC,
which
has
nothing
in
it,
but
there's
bar
depth
and
food,
which
are
three
files.
So
when
I
do
git,
commit
and
create
a
new
one
and
get
cat
fire.
B
B
There
is
ABC
here
and
but
because
ADC
is
empty,
it
doesn't
care
about
it,
because
git
only
cares
about
files
and
the
current
as
per
get
us
concerned.
Even
if
I
do
rmt,
I
r
d
c,
it's
the
same.
So
if
you
see
kit
status,
if
nothing
changed
and
if
you
see
LS
bar
the
food,
these
are
the
three
files
and
if
you
see
the
depth
here,
which
got
moved
from
ABC,
but
so
right
up
here
yep
it
has
the
same
hash
ID
as
the
old
one.
B
B
C
B
That's
a
really
good
question
because
it
gives
us
very
into
the
thought
process
of
git
about
cleaning
up
of
objects.
Now,
if
you
look
at
the
tree
structure
here
this
diagram,
rather,
this
tree
is
still
usable.
That
is,
if
someone
wants
to
go
back
to
come
at
4.
They
need
this
trade
to
go
back
to
common
mode.
So
all
objects
in
this
diagram,
which
are
reachable
from
the
comments,
will
never
get
deleted.
B
So
that's
kind
of
what
git
does
any
object,
which
is
reachable,
will
never
get
deleted.
So
git
has,
if
you
know
it
has
a
garbage
collection
which
runs
from
time
to
time.
I
believe
one
of
our
training
is
also
about
housekeeping
and
how
gitly
does
it,
but
the
car
to
give
you
some
food
for
thought
there
is
that
the
garbage
collection
tries
to
clean
up
objects
which
are
not
required,
but
in
our
instance
all
our
objects
are
required
because
all
of
them
are
reachable.
B
There
could
be
a
day
tomorrow
where
someone
says
I
want
to
move
back
to
Comet
three
or
I
want
to
move
back
to
comment
2,
and
they
should
have
all
the
objects
associated
with
that
comment.
So
in
this
craft
structure
that
you
have
anything
which
is
reachable
will
always
stay
Within.
So
when
does
a
good
thought?
Is
when
and
do
objects
get
created
which
could
be
deleted,
but.
C
B
All
right,
I
think
that's
kind
of
a
good
intro
to
how
blobs
trees
and
comments
work
and
I'm
just
going
to
show
you
that
our
objects,
folder,
is
just
increasing
with
each
of
these
things
that
we
do,
and
if
you
see
now,
we
have
16
files,
but
before
we
go
into
pack
files,
I
just
wanted
to
talk
about
the
git
folder.
Maybe
just
do
a
let's
get
so
the
git
folder
is
mostly
a
folder
where
it
does
most
of
the
things,
and
these,
as
we
already
saw
there,
are
multiple
folders
here.
A
B
C
B
So
this
is
where
all
the
repository
level
configurations
stay,
so
there's
a
lot
of
options
that
git
provides
and
I
believe
they
have
a
web
page
stating
all
of
these.
You
could
probably
go
and
check
it
there,
but
yeah
so
all
configurations
and
for
the
sake
of
this
I'm
gonna
revert
back
to
my
right
and
then
head
head.
So
again,
let's
do
this
LS,
so
we
cover
config.
A
B
B
Yeah
so
here
it
says:
hey
I'm,
referring
to
something
called
as
refs
Master,
which
is
nothing
but
the
branch
master.
So
instead
of
directly
saying
I'm
at
this
comment,
it's
saying
I'm
at
this
branch
and
if
I
can
print
this
branch,
which
is
git,
that's
ads
master
that
should
hold
this
commit,
and
that
is
the
commit
we
arrived
so
log
one
line,
it's
kind
of
what
it
is.
So
this
is
like
a
symbolic
reference
to
another
reference
which
holds
the
actual
value
available.
B
B
And
now
get
points
to
7
0
1,
so
instead
of
pointing
to
a
branch,
because
none
of
the
branches
point
is
seven
zero
Master
points
to
C5,
which
is
here
so
it
directly
points
to
this
community,
so
I'll
just
check
out
back
okay
and
now
again
it
points
back
to
muscle
as
simple
as
that.
Next
we
go
to
index
index
is
what
happens
when
you?
Let's
say
you,
add
a
new
file.
B
B
And
this
index
is
more
of
a
staging
file
which
says:
what
are
the
files
is
attract
and
can
be
completed
as
anyone.
So
if
you
try
to
print
it,
I
believe
it's
in
binary
format,
yeah.
It
should
be
in
binary
format,
but
I
think
there
is
so
for
index
yeah
similar
to
yeah.
So
this
is,
if
you
do
LS
files
stage,
it
shows
what
are
the
files
which
are
being
staged,
and
this
is
primarily
that
the
data
which
index
holds
but
it's
in
binary
formation,
but.
B
B
This
file,
we
are
clear
and
let's
move
on
to
the
next
part,
so
next
is
logs,
so
git
kind
of
logs
every
step
that
you
do
so
this
is
kind
of
useful
in
debugging.
So
now,
for
example,
if
I
do
anything
here
which
adds
a
commit
or
anything
like
that,
get
tracks
it.
So
let's
just
look
at
this
log
folder,
which
kind
of
gives
us
some
headline
towards.
B
B
Did
that
time
you
can
do
git
check
out
some
other
comment,
and
then
you
can
do
git
check
out
Dash,
which
is
like
go
back
to
whatever
before
and
how
git
knows
where
you
are
before
is
because
it
has
these
logs,
yeah
and
finally,
with
there
is
also
refs
here,
which
also
tracks
like
what
what
are
the
different
stages
that
the
any
branch
you
have.
This
is
mostly
like
a
logging
so
that
you
can
revert
back
to
changes
and
get
rid
of
problems,
so
a
good
command
to
always
use
is
reflog.
B
So
if
you
see
Git
reflog,
it
shows
you
this
login,
readable
format.
This
helps
you
like
go
back
to
different
stages,
that
you
are,
for
example,
if
you're
trying
to
do
a
merge
and
you
fail,
and
you
just
want
to
clear
everything
you
can
always
open
the
refluxy
where
you
are
and
just
like
go
get
reset
hard.
Maybe
to
that
point.
B
So
moving
ahead,
original
head
is
it's
kind
of
what
git
stores
similar
to
head,
which
is
used
for
dangerous
situations
like
like
I
mentioned,
like
when
you're
doing,
merging
or
rebasing,
and
you
end
up
in
a
scenario
where
something
is
broken
and
original
head
at.
That
point:
has
the
value
of
git
before
you
did
those
dangerous
operations?
B
So
the
idea
was
that
you
could
always
do
something
like
git,
reset
and
original
hair.
So
go
so
you
can
go
back
to
what
was
the
state
before
you
did
something
as
far
as
I
know,
git
merged
and
rebates
are
the
only
things
which
set
these
set.
The
original
head
I'm
going
quickly
over
the
next
few
months,
comment
message:
edit
messages,
the
message
that
you
have
when
you
do
a
comment
it's
stored,
so
you
can
open
a
file,
editor
and
change.
B
This
comment
message
so
I
think
the
last
one
was
C5
and
it's
just
storing
that,
for
example,
description
is
what
it
used
to
store
the
description
about
the
repository.
Mostly
people
don't
use
this
because
they
use
git
forges
like
gitlab
to
store
their
repositories
and
gitlab
has
their
own
way
of
showing
what
a
repository
is
about
mostly
through
readmes
or
descriptions,
is
why
I
did
learn.
B
Hooks
is
a
famous
One,
so
there
are
a
lot
of
applications
of
yeah,
so
you
want
a
lot
of
to
do
a
lot
of
things
when
git
does
certain
operations,
so
let's
say
once
you
want
to
before
a
commit
is
applied.
You
want
to
do
check.
Let's
say
you
have
an
npm
folder
and
you
want
to
run
prettier
on
it
to
see
if
all
the
files
conform
to
a
standard
and
what
you
would
do
is
you
try
to
hook,
which
says
right
before
the
commitment
commit
is
created?
B
Please
check
that
all
files
confirm
to
the
standard
and
that's
the
hooking
mechanisms
that
git
provides.
These
are
the
different
stages
upgrade
that
you
can
add
a
hook
to
and
they
have
sample
files
here.
Basically,
you
just
need
to
create
one
with
the
same
without
the
sample
and
make
it
an
executable,
and
you
can
hook
into
the
kits
life
cycle,
so
that
leaves
us
with
info
objects
and
refs
objects.
We
already
covered
info.
B
Yes
info
is,
if
I'm
not
wrong,
it's
metadata
that
git
uses
to
do
things.
Certain
things
like
having
alternate
object
storages,
so
we're
not
going
to
go
into
alternate
object
storages,
but
the
idea
is
that,
right
now,
all
of
our
objects
are
here
in
git
objects,
but
you
can
also
have
another
folder
outside
somewhere,
which
has
certain
objects,
and
you
want
to
say
hey.
Some
of
the
objects
are
here.
Some
of
the
objects
are
in
this
alternate
folder
and
to
know:
where
are
these
different
objects?
B
Folders
that
you
have
the
infos
folder
is
used
moving
on,
they
get
objects.
Folder
is,
as
we
spoke
about
all
the
objects
that
are
part
of
this
repository
are
in
the
objects
folder
and
finally,
the
refs
are
all
the
references
that
is
branches
and
tags.
Now
that
we
understand
how
comets
and
trees
work
references
are
nothing
but
pointers
to
those
comments.
So
if
you
have
a
branch,
let's
say
if
I
create
a
new
Branch,
give
check
out
Branch
new,
it's
nothing
pointer
to
the
comment
that
you
have.
B
So
if
you
see
the
log
one
line,
we
had
five
comments
and
new
is
pointing
to
this,
commit
if
I
just
go
and
see
what
wraps
heads
heads
Heads
is
the
base
for
branch.
So
if
you
see
new,
it
just
points
to
that
comment
and
if
you
see
similarly
master
it
just
points
that
come
and
now
since
I'm
on
new.
If
I
do
to
reset
new,
to
let's
say
two
commits
behind.
B
C
A
B
B
B
Yeah,
so
if
you
see
here
what
happened
was
that
one
c
one
C,
two
c
three
were
common
for
both
the
branches
but
Master
after
C3
has
C4,
C5
and
M1,
which
we
created
just
now,
whereas
new,
which
was
created
on
top
of
C3,
has
B1
and
P2
so
new
kind
of
deviated
away
from
Master
at
some
point.
So
now
it's
still
the
same
concept
that
get
if
you
print
Master
it
points
at
4
4
at
day,
one
which
makes
sense,
and
if
you
print
new,
hit
points
and
something
else
C3.
B
So
they
still
point
us
to
different
commets.
It's
just
that
the
commit
tree
that
was
there
diverged
at
some
point.
So
this
goes
back
to
the
thing
where
we
learn
that
all
these
objects
will
still
remain
because
there
are
Pointers
which
reference
those
objects
now,
the
only
time
a
cleanup
could
happen,
for
example,
is
when
let's
say
the
new
Branch
gets
deleted,
then
no
one
is
pointing
to
these
two
commands,
because
right
now,
new
is
pointing
to
this
one.
B
Right
going
on,
we
will
go
to
the
last
topic
for
today,
which
is
backfires,
so
we
understood
how
all
of
these
work,
and
now
we
have
an
idea
about
objects
and
how
the
object
directory
is.
But
a
big
caveat
of
this
is
these
are
called
lose
objects
in
git
terminology.
So
the
big
caveat
of
this
is
that
all
these
objects
that
exist
keep
bloating
up
like,
as
the
repository
keeps
increases
and
there's
going
to
be
a
lot
of
objects,
especially
when
there
are
single
line
edits
like
John
mentioned.
B
So
there
was
this
idea
that
kid
thought
that
okay,
let's
what
if
we
put
all
these
objects
together
inside
one
big
file
and
in
that
file,
we
store
each
object
as
a
Delta
of
another
object.
So
that
means
now
you
get
rid
of
things
like
storing
the
whole.
Let's
say
file
when
there's
only
a
single
line
change,
so
that's
what
pack
packed
refs
is
so
pack,
as
the
name
suggests.
B
A
B
B
B
So
now
we
are
going
to
do
git
GC,
where
generally
the
garbage
collection
runs
on
particular
heuristics
whenever
let's
say
you're
doing
a
lot
of
pushers
pulls
or
commits
it
sees
if
those
heuristics
are
met
and
it
will
run
it
automatically.
I
am
manually
running
it
so
that
it
does
the
garbage
collection
here
and
now,
if
you
see
you
can
see
that
it
did
Delta
compression
and
it
counted
all
the
objects
and
I
believe
yes,
so
it
created
craft.
C
B
And
I
will
talk
about
all
of
that.
So
now,
if
you
see
that
if
you
see
the
pre-structure
for
git
objects,
not
to
packs
concrete,
so
this
is
one
set
of
packs
and
this
is
the
other
set.
The
different
extensions
differ
to
different
things
that
the
pack
file
contain
like
contains.
I
will
talk
about
that
in
some
time,
but
if
you
see
all
of
the
objects
got
clear,
so
all
these
objects
that
we
had
got
put
into
Pampers.
B
B
B
B
And
that's
because
git
characterizing
sees
what
are
the
objects
which
are
loose,
which
is
what
it
says:
craft,
which
is
no
longer
pointed
by
anything,
and
it
puts
those
in
a
paper
which
can
be
cleaned
up
later
and
the
other
objects
which
are
have
pointers
to
them
and
can
be
used
at
any
particular
point
of
time
they
are
put
in
the
other
platform.
That's.
B
A
Yeah
that
was
really
good,
I
think
that
was
pretty
comprehensive.
Of
course
you
could
take
any
of
those
topics
and
do
like
a
separate
presentation
on
it,
but
I
think
we'll
call
it
there
I
don't
see
any
other
questions,
but
so
thank
you.
Karthik
I
think
that
was
really
helpful
for
a
lot
of
us.
I
will
post
this
on
our
YouTube
channel
the
recording
so
and
feel
free
to
let
your
team
members
know
about
this.