►
From YouTube: Create Deep Dive #2: Diffs and Commenting on Diffs
Description
In this Deep Dive session, Oswaldo Ferreira, Backend Engineer on the Create team at GitLab, shares his knowledge of GitLab's Diffs and Commenting on Diffs functionality.
Download the slides: https://gitlab.com/gitlab-org/create-team/uploads/b5ad2f336e0afcfe0f99db0af0ccc71a/Create_Deep_Dive__Diffs_and_commenting_on_diffs.pdf
Learn more about Deep Dive knowledge sharing sessions: https://about.gitlab.com/handbook/communication/knowledge-sharing/#deep-dive-sessions
Find out when the next Create Deep Dive is taking place: https://gitlab.com/gitlab-org/create-team/issues/1
---
Read more about our product vision: http://bit.ly/2IyXDOX
Learn about FOSS & GitLab: http://bit.ly/2KegFjx
Get in touch with Sales: http://bit.ly/2IygR7z
A
Hello
welcome
everyone,
so
I
think
we
can
start
right
now.
So
this
is
the
second
the
type
of
the
creatine,
and
we
are
going
to
talk
about
the
diffs
and
commenting
on
this,
the
first
one
which
was
with
Thiago.
It
was
great
and
we
have
the
links
on
the
the
issue
on
the
grey
team.
So,
let's
get
started.
A
So
today,
I
want
you
to
have
a
look
at
what
exactly
addictive
is
in
a
level
of
get
itself
just
a
brief
overview.
Where'd
represent
this
song.
It
lab
itself
on
a
quick,
Timo,
introduction
and
overview
of
how
its
storage.
How
do
you
fashion?
We
present
that
both
on
get
lied
and
Italy
itself,
so
we
are
going
to
have
a
look
on
the
standard
comparison
view.
A
The
merger
quest
dips
on
request,
and
this
for
comments
on
logic,
will
request
or
commits
itself
so
a
little
bit
what
we
are
going
to
do
today,
we
are
going
to
have
a
look
at
the
demo
workflows,
the
tables
that
we
use
to
start
the
deeps.
The
caching
layers
in
brief
cool
dive,
so
feel
free
to
ask
any
question
anytime.
That
there's
no
no
issue
to
interrupt
me,
but
we
have.
We
are
going
to
have
a
question
Q&A
in
the
end,
so
big,
what
exactly
get
it
good,
devious
so
get.
A
This
is
a
deep
function
that
takes
two
data,
sets
and
outputs
the
difference
between
those.
So
we
can
pass
a
commit
range
files
and
it's
interesting
because
this
this
structure
shows
that
we
have
a
comet
and
it
points
to
a
tree.
So
let's
say
we
have
a
readme
that
points
to
a
blob
and
we
have
a
lip-lip
folder
that
points
to
another
tree,
so
that's
basically
how
they
diff
our
structure
structure,
the
objects
on
git.
So
we
can
use
this
these
shots
on
git
diff
itself.
A
So
it's
interesting
because
it's
a
very
powerful
function
and
to-
and
we
are-
we
have
most
of
the
functionalities,
but
we
don't
have
everything.
So
it's
interesting
to
keep
in
mind
that
we
use
the
most
famous
part
of
the
get
if
on
on
gitlab
itself
by
the
UI
and
wrapping
the
the
clients,
but
we
don't
have
everything
so
on
the
Left.
Basically,
what
the
git
diff
is
on
the
terminal,
a
simple
difference
between
files.
A
A
I'll
quickly
show
so
this
the
ripple
compare
I'm,
not
seeing
the
chat
right
now.
So
let
me
just
check
if
there's
a
okay
there's
nothing.
So
we
have
the
hippo
compare
middle
here,
so
we
can
basically
with
what
we
can
do
here,
is
selecting
the
source
range
or
a
revision.
I
commit
itself
and
the
target
branch
click
compare
and
see.
Basically
what
exactly
kicked
if
this
we
compare,
but
it's
interested
should
think
that
here
we
are
not
fetching
the
database
at
all,
so
we
don't
have
anything
persisted
here.
We
can't
leave
comments.
A
We
don't
have
a
merge
request.
Obviously
we
have
just
a
few
files
being
being
shown
the
difference
between
those.
We
can
actually
view
the
blobs
of
the
files
here.
So
it's
also
nice
and
we
show
that
a
button
here
that
we
already
have
the
merge
request
for
this
difference.
So
we
check
that
we
have
the
each
source
and
target
range
I'm
going
to
quest
already
created
for
this.
A
So
here's
the
the
multi-class
UI.
As
probably
you
already
know,
we
have
G
changes
here.
That's
mostly
the
same
thing
of
the
comparison,
but
here
we
have
a
nice
concern.
Ality
of
leaving
comments
anywhere
anywhere
exactly
because
we
can
actually
unfold
these
lines
now
here
it's
a
new
feature
and
we
can
leave
comments
here
as
well
and
any
comments,
a
comment
that
we
leave
here.
We
just
track
those
here
as
well,
so
we
also
have
this
here.
A
A
All
right,
so,
let's
start
with
T.
Let
me
move
this
here.
Okay,
so,
let's
start
with
the
workflow
of
the
standard
comparison
view
dips
compared
to
the
other
workflows,
it's
a
little
bit
simpler
because
we
don't
persist
anything.
We
don't
actually
need
to
persist
right
now,
so
fetching
we
just
submit
a
request
to
Italy
there's
an
RPC
that
we
used
you
to
fat
diffs,
that's
common,
actually
use
it
almost
everywhere.
That's
the
Committee
for
PC!
A
We
are
going
to
take
a
look
this
on
the
end
and
we
send
the
limits
and
in
the
reference
that
will
you're
going
to
diff,
it's
interesting
to
think
about
limiting,
because
we
don't.
We
can't
just
fetch
everything,
because
we
can't
handle
everything
possible.
So
imagine
that
we
take
the
first
revision
of
it
lab
and
the
last
revision
it
lad.
Let's
say
they
mastered.
We
are
going
to
have
a
huge
amount
of
the
files.
A
So
we
need
to
to
limit
this
somehow
so
it's
nice
because
before
we
are,
we
were
limiting
on
the
gitlab
c
code
base
itself
and
we
started
moving
this
limitations
to
get
Li.
So
that's
the
source.
So
it's
it's
interesting
to
think
that
we
are
limiting
the
D
from
the
source
itself.
We
are
not
fetching,
then
putting
on
memory
and
limiting
on
it
lanced
EE.
So
it's
it's
better
to
have
a
service
that
already
does
this
and
it's
going
so
it's
faster
and
the
presentation
part
we
on
the
get.
A
Let's
each
side,
we
fetch
those
those
D
files
as
a
string.
If
you
think
about
this,
is
the
diffuse,
basically
a
string-
and
we
put
this
on
the
D
file
in
the
high-level
overview
and
we
parse
this
string
and
the
output
of
this
is
the
define
object
and
we
are
going
to
have
a
quick
look.
What
exactly
did
define
of
the
object
is
and
something
to
have
in
mind
that
we
are
not
loading
async
only
comparison
view.
We
are
just
slowly
everything
that
once
a
plane
object
playing
request.
A
Each
email
request
just
once:
that's
because
we
we
are
actually
planning
to
move
this
forward.
I
think
we
have
an
issue
for
this
of
just
link
when
I
have
it,
but
we
are
thinking
probably
thinking
on
loading,
those
dissing.
So
that's
something
that
we
already
have
for
the
merge
plastics,
so
the
multi
quest
issue.
Let's
separate
this,
some
three
parts:
LED
storage,
fetching
presentation
because
we
have
storage.
A
No,
so
there
are
two
main
tables
that
we
have
to
have
in
mind
when
working
with
multicast
ifs,
those
are
the
merge
request,
tips
and
the
modulus
D
files.
So
in
a
high-level
idea,
the
merger
quest
tips
is
the
basically
declaration,
so
each
push
that
we
central
request.
We
create
a
new,
more
request
if
and
this
more
requests
if
points
to
more
requested
files.
So
if
you
think
about
it,
every
version
will
create
hit,
create
all
the
requested
files.
A
So
that's
interesting
at
the
same
time
that
we
have
everything
storage
and
we
have
the
the
tracking
of
everything
on
the
database
and
we
don't
have
to
go
to
Italy
to
practice.
There's
a
downside,
because
we
we
just
built
a
little
bit
to
the
database
for
doing
this,
and
we
are
planing
to
to
move
cheese
this
you
through
to
outside,
so
using
object,
storage,
for
instance.
We
have
an
issue
for
this,
so
baseball.
What
I
said
before
I
think
there's
a
question.
All
right,
Nick
just
link
it
teach.
A
We
had
the
link
here
as
well,
so
thanks
oops,
so
basically
the
workflow
is
when
a
pushes
receive
it
on
the
source
page,
we
created
the
multipath
version
that
already
said,
and
we
use
this
class
choo-choo
basically
creates
the
module
quest,
ifs
and
clear
the
cache
we
have
lightning
cache.
I'll
talk
a
little
bit
about
why
the
cache
did
the
high
lightning,
but
we
erase
the
cash
here
just
a
quick
overview
because
we
use
hush
Huijin.
So
imagine
that
the
the
input
is
the
bait
de
dish.
A
The
plaintiff
in
the
output
is
the
HTML
that
we
need
to
handle.
So
if
you
think
that
on
the
go,
we
need
to
do
this
every
time
I
would
a
request
comes
in.
Imagine
that
yet
it's
a
really
heavy
process
and
we
started
doing
this
work.
Language
request,
diffs
and
after
this,
for
the
big
comments,
ifs
itself,
but
we
are
going
in
detail
later
on.
A
So,
as
I
said,
we
started
thinking
about
the
the
size
of
the
tables
that
start
that
are
going
way
too
high
Nick's
already
working
on
this
issue
that
that's
going
to
start
the
object,
storage
and
probably
we
are
going
to
have
external
references
in
the
database.
I
still
don't
know,
but
let's,
let's
see
the
demo
request
after.
A
Yeah,
so
the
the
fashion
workflow.
Basically,
instead
of
going
to
get
li
itself,
we
go
to
the
database.
We
are
going
to
have
a
quick
look
on
the
code
life
after
this,
but
there's
a
class
interesting
to
have
a
look
and
we
will
fresh
the
cache.
So
the
cache
is
written
when
we,
when
we
load
the
disk
itself,
because
we
we
raise
the
cash
after
seven
days.
So
that's
the
exploration.
A
So
when
you
we
first
of
all,
we
just
rewrite
the
cache
as
well
part
of
the
process,
also
fetches
the
deep
stats,
and
that
that
part
is
interesting.
Just
a
second
now,
this
part
is
in
store
interesting,
because
we
we
use
it
to
parse
the
the
actual
string
to
get
the
additions
and
deletions
and
the
file
path
we
already
know,
but
we
had
to
parsley
the
string,
as
you
may
think.
This
is
a
little
bit
boring
because
we
have
to
load
this
on
the
the
memory
and
parse
everything.
That's
CPU
bound.
A
So
it's
not
that
good.
So
we
left
this
job
for
an
RPC
that
we
just
request
and
under
the
hood
we
use
the
dish,
no
stats,
the
the
five.
So
it
does
the
job
first,
it
just
returns
the
additions
and
deletions.
So
it's
it's
nice
and
there's
another
point
that
I
showed
that
we
can
expand
the
diff
and
leave
a
comments.
So
we
use
the
gitlab
deep
lines
of
folder
to
like
inject,
because
if
you
think
about
what
a
DD
file
is,
is
basically
a
small
part
of
the
file.
A
So
we,
if
we
expand
this
on
the
UI,
we
are
requesting
this
for
four
blocks,
so
just
merging
bloodlines-
and
we
have
to
remember
this
when
Drew
Henry.
So
so.
The
idea
here
is
that
if
someone
leaves
the
comment
outside
an
expanded
part,
we
have
to
merge
this
on
the
fly
to
have
these
lines
from
the
develop
itself.
So
the
diff
gets
bigger
because
we
are
merging
from
the
blob
lines.
So
that's
a
kind
of
a
hacky
way,
but
still
basically
the
only
way
to
do
that.
A
Unlike
the
standard
comparison
view,
we
load
those
I
spacing
and
we
use
the
defile
entity
and
basically
JSON
and
if
you
think
about
the
size
that
the
diffs
can
get
and
we
started
seeing
that
a
few
dips
were
getting
way
too
big,
so
the
JSON
actual
JSON
after
processing
everything
and
trying
to
load.
We
started
seeing
a
few
gifs
that
have
eight
megabytes
so
more
than
that.
A
Sometimes
so
we
are
thinking
about
strategies
so
at
first
that
the
easier
the
easiest
one
would
be
just
checking
and
making
sure
that
we
are
using
everything
on
the
front
end
being
a
serialize
it,
because
sometimes
we
reuse
a
few
serialize
errs,
and
sometimes
we
get
more
things
that
then
we
actually
need
so
that
CPU
being
wasted,
and
that's
also,
we
had
to
do
to
actually
download
baby
ho
Jason
at
the
end.
So
but
it's
not
good!
A
We
need
you
to
be
aware
that
we
actually
using
everything
and
the
second
part,
that's
also
interesting
that
that's
a
nation
being
linkage
here
that
we
are
discussing
unless
model
wage
show
200
AD
Deeks.
Today
we
we
first
in
the
first
load.
We
show
the
emerging
class
reach
it
and
we
just
start
loading
the
diffs,
so
it
takes
some
time
depending
on
the
type
only
the
size
of
the
deep,
the
dips
itself.
A
So
we
started
thinking
okay,
so
we
can
load
at
least
the
first
part
of
the
defect
list,
2
or
3d
files
and
sequentially
batching
matching
the
request
for
the
next
ones.
So
when
different,
they
lose
the
the
users
first
loss,
the
the
page.
If
you
can
see
at
least
something
so
it
would
probably
lead
to
a
better
UX.
So
there's
there's
some
interesting
discussion
there.
A
If
someone
wants
to
take
a
look,
so
the
cash
flow
news,
as
we
already
talked
a
little
bit,
so
the
idea
was
that
at
the
time
that
we
created
this,
this
merger
was
the
files
table.
We
had
the
mission
to
load
the
the
merge
request,
ifs
after
the
fact
that
it
was
merged.
So
at
the
time
I
think
we
didn't
have
the
keep
around
graphs.
So
we
started
losing
some
references,
so
we
needed
some
some
way
to
keep
track
of
the
diffs
after
the
fact
that
it
was
murdered.
A
A
So
I
think
the
last
part
is
the
the
discussions
tab.
If
you
think
about
what
we
present
there,
it's
just
a
small
amount
of
the
dibs
and
we
are
going
to
see
a
little
bit
about
this.
Also,
the
storage
fetching
in
presentation
splitting
so
the
first
part
the
most
important
columns
that
we
have
on
notes.
So
it's
the
line
code,
that's
basically
the
file
path
as
a
shot
and
there's
a
the
outline
in
new
line.
So
it's
basically
user
to
link
to
the
diff
itself.
A
And
the
second
table
is
the
note
e
files
and,
if
you
think
a
little
bit
to
be,
we
could
be
using
the
merge
requested
files
because
we
already
have
confirmations
right.
We
have
operations
of
the
multi-faceted
files
on
the
database,
but
the
problem
is,
we
started
deleting
after
deleting
the
multi-class
D
files
after
the
merge
request
was
merged,
so
just
just
keep
them
keeping
the
latest
ones.
A
So
the
main
positions
that
we
have
are
the
original
one,
the
position
itself
and
the
change
position
that
we
start
as
a
serialized
object
that
we
can
see
down
below
here.
So
the
original
one
it
presents
the
original
state.
So
imagine
leaving
a
comment
on
the
the
diff
step.
So
that's
the
object
that
we
want
change
so
that
points
to
to
the
original
version.
So
let's
say
so.
A
We
use
that
on
the
discussion
tab
if
you
think
about
that
the
dish
is
not
is
never
exchanged
on
the
discussion
that,
because
that's
the
states,
that's
it
that
it
was
at
the
time
that
you
left
the
the
comments.
So
the
original
position
is
TD
responsible
for
this
position
basically
follows
the
DeMars
request
version.
Unless
the
the
line
was
changed
as
a
client
that
was
left,
the
comment
was
changed
and
they
changed
position
tracks
when
they
did
the
exact,
if
that
defined,
that
was
commented
was
changed.
A
So
we
that's
that,
that's
because
the
name
change
position,
so
we
store
exactly
the
the
the
point
in
time
that
we
we
change
it
this
in
that.
That's
what
you
use
it
here.
Church
present
this
in
this,
for
instance,
version
eight
of
the
dish
so
that
links
to
the
diff
itself.
So
we
can
see
the
difference
between
version.
We
have
an
issue
for
actually
presenting
the
difference
that
just
linking
I
think
now
it
has
has
the
link
or
just
leave
the
link
on
the
the
comments
here
so.
A
So
so,
basically,
the
storage,
workflow
I
think
that
the
main
takeaway
here
is
that
we
don't
persist
everything.
So
we
just
need
the
the
from
the
topmost
position
of
the
diff,
the
actual
string
to
decremented
line,
and
you
can
ask
why,
with
me
the
error
from
the
top.
Should
it
be
recommended
recommended
line?
That's
because
we
need
the
header
information
in
the
header.
Information
normally
stays
in
the
topmost
position,
so
it
just
cuts
the
beef
and
persist.
A
This
would
be
would
be
possible
to
just
cut
the
the
context
that
we
need
and
rewrites
the
B
header
on
the
D
string,
but
with
it
would
be
a
little
bit
more
complex.
So
we
just
cut
everything
that
we
need
Ian,
Percy
straight
away
and
use
that
to
person
to
the
the
whole
process
that
the
read
works
for
for
parsing,
three
different,
creating
deep
lines
that
are
what
we
already
explained
a
little
bit.
A
So
when
the
diff
updated
a
Bush's
sense,
we
used
a
good
lab
disposition
tracer
to
just
trace
where
exactly
the
position
is
to
be
on
the
next.
If
so,
imagine
that
I'll
push
that,
since
we
already
have
the
comment
there
on
the
the
diff
step,
but
we
need
to
know
where
exactly
the
the
comment
needs
to
be
in
the
next
in
the
next
version.
A
So
if
the
line
exactly
lying,
the
exact
line
that
was
commented
was
changed,
it's
updated,
so
it
won't
go
to
the
latest
version.
So
if
we
can
track
the
divine
that
just
changed
the
position,
let's
say
it
was
it
was
in
line
10
and
the
it
was
moving
to
line
12.
We
can
track
with
the
disposition
tracer
that
we
need
to
present
in
the
next
version
induces
a
client.
So
that's
the
guy
that
does
that.
So
the
caching
layers,
we
have
possiblys
again
that
we
just
persist
the
different.
A
So
as
we
already
talked
it,
we
and
the
the
reason
why
we
started
persisting.
This
is
that
we
were
not
noticing
that
we
are
request
work.
We
were
requesting
Italy
all
the
time.
So
imagine
that
we
have
merge
request
with
a
hundred
comments,
so
we
would
need
to
be
fetching
Italy
I
like
a
hundred
times,
sometimes
depending
on
how
many
revisions
that
we
are
requesting.
So
we
started
seeing
that
it
was
getting
a
little
bit
of
country
out
of
control,
and
we
just
noted
that
we
could
do
this
little
persistence.
A
That
would
improve
a
lot
the
performance
and
the
same,
the
same
problem
that
we
have
did
with
the
merger
questi
files,
the
actual
dish
of
the
more
requests
we
started.
Seeing
on
the
discussion
tabs
as
well,
we
started
seeing
that
we
were
processing
the
high
lightning,
the
actual
HTML,
taking
a
lot
of
time
to
process
this.
So
we
use
it
basically,
the
same
strategy.
A
So
the
question
is:
could
we
go
away
with
the
code?
The
keep
keep
around
wraps
now
that
we
have
the
emergency
fires?
Yeah?
That's
a
good
question!
Actually
yeah.
We
I
think
we
could
just
reuse.
We,
we
probably
would
see
some
performance
like
getting
worse
a
little
bit.
Probably
but
that's
doable.
That's
normal
I!
Don't.
B
Think
we
could,
because,
if
the
merge
request
is
merged
at
some
point,
the
and
the
actual
commits
that
made
up
the
original
diff
somehow
are
not
in
any
branch
anymore
and
they
get
cleaned
up.
If
we
want
to
view
those
blobs
want
to
expand
some
of
the
hidden
diff
lines,
we
still
need
to
have
access
to
the
underlying
blob
which
might
get
cleaned
up
before
you'll,
never
keep
around.
A
B
Absolutely
there
has
to
be
a
way
and
I
think
that
the
CI
thing
was
looking
at
this
at
least
years
ago,
already
of
kind
of
deduplicating
them
or
reducing
the
amount
of
keep
you
around
refers
to
the
minimum
set.
We
actually
need
to
cover
all
those
commits,
because,
obviously
that's
the
goal-
and
there
are
a
lot
of
redundant
ones,
that
we
should
be
able
to
remove
I,
don't.
A
It
created
an
issue
a
long
time
ago.
Just
talking
about
do
we
actually
need
to
persist
everything
do
we?
Could
we
just
request
Italy
all
the
time,
because
that's
not
that
bad
sometimes
so,
would
be
reducing
the
complexity
just
having
to
keep
everything
on
the
database,
so
that
would
reduce
the
the
problems
with
table
sizes,
so
I
hope
just
link
the
issue
that
I
created
some
time
ago
would
be
nice
to
discuss
this
there.
So
so,
let's,
let's
have
a
quick
look
on
the
code.
A
A
Have
a
few
files
here,
let's
see
so
the
first
one
here
is
the
the
merge
request
reload
if
service,
as
you
may
think
that
that's
its
that's
use
it
when
we
receive
a
push.
So
it
does
a
few
things
here.
It
creates
the
Mojo
past
it
and
create
a
module
pass,
the
files
as
well.
It
clears
the
cache
that
we
have,
because
we
need
to
keep
the
latest
and
this
triggers
the
update
of
the
position.
So
we
need
to
know
where
the
the
comments
will
be
so
it
just
triggered
there.
The
positions
update.
A
So
this
is
a
little
low
level
would
be
nice
to
actually
present
the
ticket
Leaphart.
Just
just
one
piece
here
that
I
that
I
separated
this
is
the
mayor
pc
that
we
used
to
fetch
the
beliefs
and
it's
pretty
straightforward.
Actually
we
receive
the
let
let's
commit
and
the
right
commit
and
receive
DD
paths
here
as
well,
and
if
you
take
a
look
here
on
the
arcs
that
we
are
actually
calling
the
gate
itself
here,
so
he
also
here.
A
We
can
see
that
if
we're
enforcing
limits
that
that
comes
from
from
they
see
they
get
lat
or
actually
the
coins.
So
this
checks
that
we,
if
you
are
enforcing
limits,
we
are
actually
using
the
limits.
So
we
are
setting
everything
here
so
on
this
part
here
we
iterates
on
the
on
the
deef
and
I
think
that
it
returns
a
string
of
thief's
that
that's
these
are
the
objects
that
that
are
returned.
It
so
lots
of
them
yeah.
A
A
So
let's
go
back
so
as
you've.
Seen
on
the
key
to
this
side
that
we
use
the
limits
being
sent
from
the
declines.
That's
the
kid
it
like
code
base
itself.
We
use
this.
We
set
this
here.
So
this
is
the
class
that
gitlab
it's
deep
collections,
basically
the
class
that
wraps
the
what
what's
coming
from
from
get
lee,
so
that
there's
some
logic
here
that
we
could
take
a
look
quickly.
A
So
let's
say
we
can
see
that
it
takes
a
look
on
with
it
sets
the
overflow
when
it
overflows
like
expands
a
certain
position.
Certain
limit,
I
think
I
think
part
of
this
is
already
done
on
on
get
a
little
aside,
so
we
need
to
delete
actually
delete
some
code
here,
I
think
so,
for
instance,
we
check
are
actually
it
comes
from
get
Lee.
A
We
can
see
over
for
Mac
marker
here,
so
we
just
set
the
overflow
to
true
overflow,
so
get
just
stop
Henry,
so
it
takes
on
some
logic
of
limiting
as
well
so
so
this
is
the
lower
level
wrapper.
Let's
say
on
the
right
side:
here
we
have
also
have
a
lower
level
object
touch
that
fetches
Italy,
so
it
also
fetches
here
place
it
on
this
between
method,
so
also
interesting
to
to
know
this
class,
and
it
just
close
this.
A
Difficult
actionable
requests.
If
and
if
you
take
a
look
on
the
on
the
suit
class
here,
the
database
class.
We
always
call
this
difficult
row
thieves,
so
basically
what
what
exactly
deformer
is
so
difficult
is
basically
I.
Compare
objects
that
I've
showed
before
here:
I,
basically
compare
methods
or
a
multi
class
thief,
so
things
that
we
can
call
relatives,
for
instance,
and
each
each
objects
helped
his
its
particular
way
to
fat
dicks.
A
So
if
you
pass
the
D
compare,
we
are
going
to
show
two
fat
from
the
ripple
itself,
because
the
relatives
goes
through
the
reboot
itself
and
if
you
pass
the
merge
request.
If
and
if
you
take
a
look
at
implementation
of
the
relatives,
is
it
actually
goes
to
the
database
instead?
So
there's
a
nice
abstraction
on
this
that
we
had
the
file
collection
request.
If
you
have
the
file
collection
compare,
so
each
of
those
super
classes
receive
this
method
that
represents
this
class
and
knows
exactly
how
to
fight
this
these
disks.
A
So
it's
a
nice
overview
so,
for
instance,
on
the
Mojo
quest.
If,
since
we
use
the
cache,
the
D
files
just
use
the
cost,
cache
decorate
for
every
D
file,
so
the
decorate
itself
don't
request
the
the
Redis
it
just
takes:
what's
memorize
it
and
just
assign
student.
If
lines,
we
can
take
a
quick
look
here
and
be
if.
A
Yeah
and
if
you
take
a
look
here,
it
just
assigns
the
highlighted
D
flights
and
the
air
we
just
iterate
on
the
content
and
create
the
Defiant's
just
create
instances
of
defiance
based
on
what
we
had
on
the
dash.
So
we
have
the
d
file
here,
the
defied
this
a
little
bit
too
much,
actually
there's
a
lot
going
on
here.
But
let's
take
a
look
at
the
deep
lines
that
we
can
understand
a
little
bit
of
the
flow
of
rendering
we
can
recall
defiance.
A
We
use
the
parser
on
the
road
if
it's
after
debts
this
drink,
we
pass
the
iterator
here
Rajeev
each
line,
and
we
can
take
a
look
here
that
we
parse
the
actual
string.
So
those
lines
are
actually
string
array
of
strings,
and
here
we
can
see
that
we
checked
the.
We
found
the
header
there.
So
since
we
know
the
headers
there,
we
know
exactly
which
wine
is
there.
So
we
can
create
multiple
lines.
So
that's
that's
the
core
of
rendering
the
deef
lines,
because
we
serialize
those
lines
and
the
front
end
just
takes
takes
everything.
A
That's
already
there
and
just
handles
in
TV,
so
hopefully,
and
so
that's
lower
a
bit
a
little
bit
lower
level
wrapper
of
the
dish.
It
knows
a
little
bit
more
about
the
delineations
itself,
so
it
takes
some
some
constants
here
to
know
what's
the
size
that
we
should
be
using
as
a
limit
it.
It
also
knows
the
that
which
we
should
request,
get
Li
the
repo
itself.
So
it
has
a
few
methods
that
that's
interesting
to
this
part
of
fetching,
so
not
much
that
high
level,
so
so
things
that
are
more
related
to
fetching.
A
Let's
see,
let's
see
yeah
it
memorizes
a
few
things
like
too
large
and
collapse
it,
for
instance.
So
when
this
object
is
passage
of
TIF
file,
it's
already
memorize
it.
So
let's
say
this
logic.
This
logic
is
already
like
flex.
It
prepared-
and
we
see
realize
this-
these
attributes
so
the
logic
of
knowing
exactly
how
to
memorize
those
those
attributes
should
be
here
most
part
of
those.
A
So
here's
the
line
that
we
created
from
the
cache
that
I
just
show
it.
It
takes
a
few
a
few
attributes
here
and
you
can
take
a
look
on
the
cache
again.
Basically,
we
call
the
image
from
from
hash,
and
that's
that's
what
it's
saying
here.
So
it
knows
how
to
respond
to
edit,
remove
it
mirror
and
change
it.
So
it
knows
what
exactly
the
the
line
represents
so
based
watered
object.
My
do
should
do
actually
and
yeah
so
the
highlight
in
cash
we
already
saw.
A
A
Hopefully
we
are
going
to
remove
this
parallel
dish
lines,
and
just
do
this.
You
just
did
the
deep
lines.
Fertilizer
I
think
that
we
we
have
a
multi
class.
You
just
remove
the
parallel
lines
and
do
these
in
the
front-end.
It's
good,
because
we
just
remove
a
few
other.
A
few
extra
megabytes,
maybe
or
just
I,
don't
know
K
bytes,
but
at
least
we
are
just
making
it
a
little
bit
faster.
A
But
it's
it's
interesting
to
think
that
the
front-end
will
be
doing
a
little
bit
more
actually
but
yeah,
let's
see
so
the
diff
node
diff
notice,
the
persistence
layer.
We
have
the
validations
on
the
original
position.
The
position
line
code
I
think
that
the
interesting
to
show
the
main
part
here
is
that
the
fetching
of
the
D
file-
and
if
we
take
a
look
here,
it's
pretty
straightforward.
A
A
Yet
we
just
try
to
fetch
this
from
the
merge
of
Class
D
files
from
the
emoji
class
tips
itself,
because
we
keep
the
latest
so
sometimes
sometimes
you
just
can
fetch
from
this
from
the
database
and
start
going
through
the
list
performance
part
that
is
just
fetching
from
from
the
repo
itself.
So,
as
I
said,
we
will
do
some
magic
on
the
unfolding
lines,
the
lines
on
folder
that
we
can
see
here.
A
Basically,
these
this
lines
of
folder
class,
the
the
whole
point
is
that
it
takes
the
position
and
it
takes
the
D
file
and
it
knows
which
one
is
that
exactly
we
need
to
fetch
from
the
blobs
to
present
this
block
of
code
that
we
did
the
user
just
commented.
So
basically,
the
return
of
this
do
for
the
diff
lines.
Are
the
deep
lines
process
it
with
the
blob
lines
that
the
extra
blood
lines
that
we
fetch
it
so
a
little
bit
just
a
little
bit
of
magic,
but
make
sense.
A
This
part
here,
okay,
so
the
the
get
lab
discussions
did
file
collection.
The
idea
here
is
correct.
All
the
discussions
did
so
imagine
the
the
discussion
tab
that
we
have
on
the
merge
request
this
this
guy
here
just
takes
all
the
DD
files
on
the
truncate,
the
chunk
it
defiles
and
knows
how
to
load
the
high
lightning
from
the
the
cache
it
knows
how
to
find
by
the
ID.
So
it's
it's
basically
a
wrapper
of
the
discussion
dish.
A
Here
we
use
a
little
bit
of
lower
level
of
the
Redis,
but
we
are
also
able
to
pass
multiple
keys
and
write
everything
at
once.
So
for
now
we
are
not
erasing
just
one
D
file,
just
writing
and
reading
everything.
We
are
just
relying
on
the
expiration
time
that
seven
days,
but
if
we
want
to
just
reread
start
to
raising
more
quickly,
we
just
could
implement
that
really
easily
with
this
guy.
So
again
the
my
son
folder
that
we
already
talked
it
so
this
this
is
really
a
really
big
and
a
little
bit
complex
class.
A
So
the
idea
here
is
taking
the
old
raft
and
then
real
rafts
on
the
point
when
the
pushes
receive
it
and
the
idea
is
knowing
where
exactly
the
the
comment
needs
to
be
when
receiving
a
new
push.
So
I
think
they.
The
output
here
is
a
result
having
I
think,
though
it
knows
a
little
bit
better,
but
basically
the
post
dish
and
if
it's
outdated
or
not,
and
so
the
new
position,
and
if
it's
updated
or
not
it,
it
returns.
What
we'd
need
to
know
to
persist
the
position.
A
A
B
C
A
A
If
physician,
so
we
were
talking
about
the
position
itself.
So
what
we
do
today
is
knowing
the
widgets
in
heights
of
the
image
and
knowing
where
exactly
the
comment
was
made
by
the
position
so
x
and
y.
So
that's
a
good
question
actually
to
to
have
a
side-by-side
and
I'm,
not
sure
right
now,
but
I
can
come
up
with
a
good
good
response
for
this
I'm,
not
sure
sorry,
we.
B
We
do
have
image/tiff
commenting
functionality,
I
think
by
default
in
the
image
that
we
have,
that
option
of
switching
between
old
and
new
and
using
that,
like
onion
paper
kind
of
view
where
you
you
know,
can
drag
the
line
and
see
the
images
kind
of
turn
into
the
other
one,
and
we
support
commenting
there
too,
and
that's
what
a
lot
of
us
pointing
out
with
those
x
and
y-coordinates,
which
we
use
instead
of
new
line
and
old
line
when
you're
commenting
on
a
changed
image.
But
for
the
most
part
everything
related
to
image.
B
Difficulty
is
implemented
on
the
front,
then
only
the
DIF
notes
when
we
store
them.
Of
course,
they
need
a
disposition
to
know
what
they
are
attached
to
and
in
this
case
that's
an
ex-wife
chord
rather
than
an
old
line
and
define
in
file
path
and
there's
a
file
path.
Of
course,
this
is
the
case
for
images
too,
but
X
or
Y
instead
of
old
line
and
in
you.
A
B
To
finish
that
thought,
from
the
perspective
of
how
it
fits
into
the
architecture
when
you
have
a
collection
of
defiles,
because
of
course
Biff
is
a
collection
of
diff
diff
line.
If
it
textiles
define,
will
have
diff
diff
lines,
but
of
course,
if
it's
an
image,
if
file,
then
it's
once,
but
the
diff
file
implements.
If
you
were
method
that
returns
a
viewer,
that
I
think
it's
all
don't
mentioned
that
as
well,
which
in
the
case
of
sex
tips,
will
be
a
text.
B
The
fewer
and
imitation
image
shapes
will
be
an
image
they're
fewer,
and
this
is
also
communicated
in
front
end.
So
the
front
end
knows
which
differ
entering
and
difficult
rendering
logics
you
branch
into
so
yeah,
exactly
diff
fewer
image.
It
doesn't
implement
all
that
much
logic
here,
because
it
includes
client-side
online
six,
which
means
that
it
leaves
the
responsibility
of
actually
rendering
this
they
have
to
perform
them
and
how
to
allow
commenting
there.
Yeah
that's
right.