►
From YouTube: (Git Merge)² - Git Merge 2022
Description
Presented by Elijah Newren
Discussing improvements in "Git Merge" at "Git Merge", hence (Git Merge)². This talk will discuss recent improvements in the merging machinery, which actually extends to several commands besides "merge". It will include:
- What new features have been enabled by the new merge backend
- How a couple of the new optimizations involve trade-offs, and what the possible behavioral differences might mean for you
- A brief story of my discovery process for finding the new optimizations added to the merge (and diff) machinery
About Git Merge:
Git Merge is dedicated to amplifying new voices in the Git community and showcasing the most thought-provoking projects from developers, maintainers, and teams around the world. Git Merge 2022 took place at Morgan Manufacturing in Chicago, IL on September 14th and 15th.
A
So
today,
I'm
going
to
be
talking
at
get
merged
about
get
merge,
hence
get
merged.
Squared
I
actually
gave
a
somewhat
similar
talk
two
and
a
half
years
ago
it
get
merged
2020,
where
I
was
talking
about
optimizations
that
were
a
work
in
progress
at
the
time
and
I
was
discussing
what
the
optimizations
were
and
why
I
believed
in
them.
I
didn't
have
them
all
implemented
at
the
time
since
that
time,
I've
got
them
all
implemented.
A
Two
of
the
three
that
I
did
have
implemented
at
the
time.
I've
made
significant
improvements
to,
and
then
I
found
additional
optimizations
as
well,
but
this
time
I
want
to
change
the
talk
a
little
bit,
because
everything
is
now
part
of
Upstream
git
and
available
in
in
use.
Today,
I
want
to
talk
with
this
new
merge
back
end.
First
of
all,
what
are
some
of
the
benefits?
A
Why
would
why
does
it
benefit
you
not
just
in
terms
of
performance,
but
some
of
the
other
features
that
have
come
along
with
that
just
weren't
possible
or
too
difficult
with
the
old
merge.
Backend
I
also
want
to,
instead
of
going
into
as
much
detail
in
each
of
the
optimization
of
how
it
works
more
discuss
how
I
discovered
it.
A
What
was
my
journey
to
get
there,
at
least
for
the
starting
path
of
what
was
my
initial
hint
to
be
able
to
find
that
thing
and
then
something
that
I
didn't
even
know
a
little
bit
at
the
time.
Some
of
these
optimizations
include
differences
in
behavior
from
the
old
merge
back
end
and
what
are
some
of
those
differences
and
before
I
can
get
into
that.
I
first
need
to
provide
a
little
bit
of
background.
First
of
all,
even
though
I've
said
get
merged.
A
A
A
Perhaps
an
example
would
be
helpful,
so
let's
say
we've
got
a
simple
file
that
exists
on
both
of
our
branches
of
Interest
I've
named
the
branches
side,
one
and
side
two,
because
I'm
boring
it's
easy
to
refer
to
them,
and
let's
say
that
we've
got
three
lines
in
this
file
of
interest
on
side.
One
and
we've
got
three
very
similar
lines
in
the
file
on
side
two,
but
the
middle
line
is
different
between
the
two.
A
A
So
if
the
merge
base
happens
to
match
side
one,
then
we
can
say
well
side,
one
didn't
make
any
changes,
so
the
merge
results
should
be
take
side.
Two
contrast
that,
with
if
the
merge
base
matches
side
2,
then
we
would
say
well
side
2
didn't
make
any
changes,
so
we
should
take
the
version
from
side
one
and,
of
course,
there's
also
the
possibility
that
the
version
of
the
merge
base
didn't
match
either
side,
and
then
we
get
our
standard
conflict
that
we
all
know
well
and
love.
A
A
A
And
so,
if
you
pass
the
remerged
a
flag
to
either
show
or
log
most
the
time,
you're
not
going
to
get
any
output
for
a
merge
commit
because
most
of
the
time
merges
are
clean,
and
so
it
just
doesn't
show
anything.
But
if
there
had
been
a
conflict
that
they
had
to
resolve
when
they
did
that
merge,
then
you
would
see
a
diff
between
where
they
started
it
at
and
where
they
ended
up
to.
A
Okay,
so,
for
example,
that
conflict
I
had
on
the
previous
screen,
this
particular
user
in
this
merge
commit,
went
and
said
you
know
what
I
don't
want.
I,
obviously
don't
want
the
conflict
markers,
but
they
also
didn't
want
the
line
on
either
sides
they
removed
them.
Those
are
all
in
red.
They
instead
added
a
new
line,
which
was
a
combination
of
sorts
of
the
other
two
lines.
A
Another
feature:
that's
very
similar
to
this
one
uses
a
reference
of
sorts
called
Auto
merge.
So
if
you're
in
the
middle
of
resolving
a
conflict
either
during
a
merge
or
a
rebase
cherry
pick
whatever
and
you've
done,
you've
resolved
several
of
the
conflicts,
but
you
still
have
more
other
ones
and
at
some
point
you're
like
you
what
I
want
to
know
what
I've
changed
so
far,
what
have
I
changed
since
the
thing
stopped
and
asked
me
to
resolve
conflicts
if
you're
on
get
diff
Auto
merge
you'll
be
able
to
see
that
information.
A
A
A
The
next
set
of
benefits,
I
kind
of
all
connected.
They
make
it
easier
for
us
to
deal
with
repository
subsets,
and
this
goes
in
a
number
of
different
ways.
For
example,
with
partial
clones
there's
a
it
provides
a
massive
reduction
in
the
number
of
files
that
need
to
be
downloaded
on
Demand
by
the
merge
machinery
for
the
sparse
Index.
This
is
actually
critical.
A
Another
Advantage
from
the
new
emerge
back
end
is
I
was
really
focused
on
Craigslist
issues.
There
are
a
number
of
tests
in
the
git
test,
Suite
that
are
marked
as
expected,
failures,
people
report
to
us
issues,
sometimes
they're
funny
Edge
or
Corner
cases,
or
we
just
haven't
gotten
to
them.
Yet
we
still
put
a
test
in
the
test
Suite,
even
if
we
don't
have
it
working
yet
and
about
23
of
the
tests
that
I
fixed
were
expected.
Failures
that
existed
before
I
even
started
working
on
the
merge
machinery.
A
There
were
another
nine
that
while
I
was
working
on
the
merge,
Machinery
I
discovered
additional
issues
since
I
was
looking
at
the
code
really
closely
created
additional
test
cases
and
those
are
fixed
and
worked
with
the
new
merge
backend,
but
not
the
old
one
and
then
also
after
the
new
merge
back
in
became
the
default.
We
had
a
report.
I
did
some
investigation.
A
There
was
an
issue
with
both
the
Old
and
the
new
back
ends
and
I
only
fixed
it
in
the
new
one
that
was
another
two
of
them
and
since
our
last
talk
was
on
sub
modules.
I'll
note
that
10
of
these
tests
that
were
fixed
were
actually
some
module
related,
so
it
improves
things
there
as
well
and
on
the
flip
side,
there's
no
tests
in
our
test
Suite
that
fail
with
the
new
back
end
and
succeed
with
the
old
one.
So
as
far
as
I
know
so
far,
it's
better.
A
Perhaps
the
thing
is
most
well
known,
for,
though,
is
performance?
I
spent
a
lot
of
time
trying
to
make
sure
that
this
new
merged
back
end
really
succeeded
well
on
performance,
I
picked
a
few
test
cases
that
were
of
interest
to
me
and
I'm
going
to
skip
not
not
provide
the
new
timings
just
yet,
as
I
get
to
later.
Slides
I'll
show
those.
A
This
is
a
problem
because
there's
no
hint
to
the
user
that
they
need
to
merge
these
two
different
files
and
even
if
they
happen
to
know
that
they
need
to
merge
those
files,
it's
not
obvious
how
to
do
so.
They're
missing
the
base
version
to
be
able
to
look
at
I've
seen
this
dealt
with
several
ways
by
users:
it's
usually
one
of
three
things,
all
of
which
are
sub-optimal
one.
They
end
up
just
keeping
both
files
around
in
the
tree,
Each
of
which
is
missing
some
of
the
changes
from
the
other.
A
They
remember
forget
the
changes
that
their
co-worker
made
to
the
file
on
the
other
side
of
history
and
then
include
that,
but
in
any
case
they
often
miss
things,
and
this
might
not
be
a
really
big
issue
if
you've
only
got
one
or
two
renames,
but
if
you've
got
a
repository,
that's
dealing
with
hundreds
or
tens
of
thousands
of
renames.
It
can
really
start
biting.
A
I
also
needed
to
discuss
a
little
bit
about
how
rename
detection
works
at
a
high
level
inside
of
git.
We
have
to
actually
do
two
sets
of
rename
detection
from
the
merge
base
to
side
one
and
from
the
merge
base
to
side
two
but
I'll.
Just
look
at
any
given
side
right
now.
First
thing
git
needs
to
do.
Is
it
looks
at
the
list
of
file
names
in
the
merge
base
and
the
list
of
files
on
the
given
side.
A
If
a
file
appears
on
both
sides,
then
it
wasn't
renamed
that
gives
us
the
remaining
set
of
files
they
might
be
deletes
and
ads,
but
they
might
actually
correspond
to
a
rename
in
the
way
it
detects
is.
It
says:
okay
for
every
pair
of
the
remaining
files,
what
percentage
of
lines
are
found
in
both
and
so
as
to
fill
out
this
big
Matrix
of
similarity
percentages
and
if
you
have
commits
where
there's
a
really
long
list
of
files
that
are
unique
to
the
base
and
really
long
list
of
files
unique
to
the
given
side.
A
And
for
me,
this
all
began
a
number
of
years
ago.
We
have
a
repository
that
had
tens
of
thousands
of
renames.
You
may
think
that's
a
lot,
but
it
turns
out
if
you
rename
a
somewhat
high
level
directory
all
files
under
it
appear
to
be
renamed.
So
you
can
just
rename
a
few
dozen
directories
and
you
get
huge
numbers
of
renames
overall
and
at
the
time
people
were
writing
custom
scripts
to
simulate
a
cherry
pick.
They
were
not
using
get
cherry
pick
for
a
couple
of
reasons.
One
there
was
silent
caps
on
merge.rename
limit.
A
That
was
one
of
the
first
things.
I
went
in
and
fixed,
but
even
if
they
had
a
case
that
weren't
affected
by
the
merge.rename
limit,
then
get
cherry
pick
with
even
small
patches,
where
someone
modified
like
five
files
and
just
made
small
changes
to
those
files,
would
still
take
more
than
nine
minutes.
Long
to
complete
that
operation
and
a
quick
warning
I've
had
to
simplify
things
quite
a
bit.
A
I,
don't
want
to
provide
all
the
details,
I
even
oversimplified
in
a
few
places,
but
I'm
still
providing
the
true
nature
of
how
did
I
discover
these
optimizations
and
what
path
I
went
down
to
get
them.
So
the
first
optimization
is
one
that
I
call
relevant
renames
and
it
comes
back
by
looking
at
those
custom.
Cherry
pick
scripts
that
people
were
writing
and
looking
at
what
they
did.
A
So
they
had
scripts
that
would
run
create
a
patch
and
then
go
Munch
that
patch,
basically
modifying
file
names
in
it.
According
to
a
set
of
patterns
that
use
repository,
specific
knowledge
and
point
in
time,
knowledge,
and
then
they
would
run
get
apply,
seems
like
a
pretty
simple
strategy.
What
was
the
result?
A
A
A
A
So
that
means
that
we
can
actually
exclude
most
source
files
from
rename
detection.
We
can
reduce
the
number
of
rows
in
that
Matrix
dramatically.
This
actually
isn't
too
difficult
to
implement.
Took
me
a
little
bit
of
time.
It
actually
goes
and
breaks
the
number
of
tests
in
the
regression
test.
Suite,
because
I
lied
to
you
about
the
purpose
of
rename
detection
there's
two
purposes,
but
the
same
basic
idea
of
when
do
I
actually
need
this
source
file
can
actually
guide
you
towards
the
solution.
A
turns
out
that
this
also
has
a
behavioral
change
as
well,
but
it's
something
that's
really
well
battle
tested
in
git
itself.
In
particular.
This
behavioral
change
is
that,
if
there's
multiple
valid
rename
pairings,
meaning
you
have
multiple
files
that
are
very
similar
in
each
commit
than
excluding
some
of
those
source
files
can
cause
the
other
files
to
be
paired
differently
than
they
otherwise
would
have
been.
A
It
has
a
function
called
build
fake
ancestor,
but
it's
algorithmically
identical
to
what
you
would
get
with
a
naive
form
of
this
optimization,
the
one
that
breaks
directory,
rename
detection
applied
just
on
the
Upstream
side.
Devstream
site
is
the
one
that
usually
has
most
all
of
the
renames,
so
anyone
who's
been
using
get
am.3
has
actually
already
been
using
this
optimization,
and
even
if
you
don't
directly
use
it,
a
lot
of
other
people
do
directly
use
it
and
you've
probably
indirectly
used
it,
because
it
Powers
one
of
our
backends
and
rebase.
A
Just
like
merge
rebase
has
multiple
back-ends
to
it,
but
it's
a
little
bit
different
in
that
you
usually
don't
explicitly
call
out
the
back
end.
Rather,
some
of
the
features
of
rebase
are
supported
in
one
back
end,
and
some
of
the
features
are
supported
in
a
different
back
end
and
so
which
backend
you
get
is
dependent
on
which
other
flags
you
provide.
A
A
We've
made
things
more
consistent,
actually
in
git,
which
is
a
nice
benefit
for
this
as
well,
and
actually
we
did
a
lot
of
work
a
few
years
ago
to
try
to
document
all
the
differences
between
the
rebase
back-ends
as
a
starting
point
for
let's
try
to
remove
some
of
these
differences.
This
was
one
that
we
missed.
I
just
didn't
know
about
it
actually,
until
like
a
few
months
ago,
as
I
was
going
over
this
a
little
bit
more
careful
detail,
foreign.
A
The
second
optimization
is
a
lot
easier
to
discuss.
I
call
it
no
copy
detection,
and
the
idea
here
goes
back
to
the
fact
that
git
stores
hashes
not
just
of
commits
but
of
individual
files
and
trees
that
provided
a
really
simple,
optimization
idea,
one
that
was
implemented.
I
think
before
I
ever
even
got
involved
in
git.
If
two
files
have
the
same
hash,
treat
them
as
an
exact
rename
and
remove
them
from
the
similarity
percentage.
Matrix.
A
It's
a
really
simple
idea,
but
the
implementation
didn't
actually
do
that.
It
would
go
and
find
the
exactory
names
and
then
only
remove
the
destination
file.
So
basically
it
would
reduce
the
number
of
columns,
but
not
the
number
of
rows,
and
the
reason
for
that
was
the
code
that
did
rename.
Detection
was
also
responsible
for
copy
detection,
and
it
wasn't
fully
aware
there
was
a
missing
place
in
one
location
of
where
it
was
knowing
whether
it
was
trying
to
do
both
or
only
trying
to
do.
A
One
merging
doesn't
have
any
use
for
copy
detection
and
turns
it
off,
and
that
basically
meant
that
what
the
code
was
doing
was
wasting
time.
Looking
for
a
better
than
an
identical
copy,
which
I
wasn't
going
to
find,
if
you
implement
this
optimization
turn
off
the
other
one
that
I
did
so
only
this
optimization
is
active.
It
speeds
things
up
by
a
factor
of
over
two
and
there
was
no
behavioral
change
from
this
one.
A
If
you
go
into
the
algorithm,
get
when
it
needs
to
rebase
a
sequence
of
commits
it
takes
the
first
one
says:
I
need
to
do
some
kind
of
merge
operation
with
that,
and
that
says
great
I
need
to
know
what
renames
were
done
on
the
Upstream
side.
It
goes
off
for
a
few
minutes,
comes
back
and
says:
there's
26
000
renames.
A
Here
they
are,
then
it
finishes
with
the
merge
with
that
commit
gets
it
all
done
goes
to
the
second
commit,
and
it
says
I
want
to
play
that
on
top
of
what
I
just
did-
and
it
says
great
I
need
to
find
out
if
there
are
any
renames
Upstream
goes
and
looks
computes
for
a
few
minutes
and
comes
back.
Hey
yeah,
there's
26
000
renames
the
same
26
000
we
computed
before,
and
then
it
repeats
this
for
every
commit,
that's
being
rebased
in
the
sequence,
and
so
naturally
the
question
comes
up.
A
Occasionally,
people
come
with
ideas
of
more
comprehensive
caching
of
renames
of
some
sort
to
try
to
speed
up
rename
detection
I'm
a
little
bit
skeptical
of
some
of
those,
especially
when
you
start
storing
that
cash
on
disk
I
think
there's
various
ways
to
make
it
unsafe
and
there's
actually
a
lot
of
ways
to
make
it
less.
Performant.
Surprisingly,.
A
A
A
A
Most
of
the
computation
and
I
have
done
most,
but
the
num,
but
the
performance
timings
aren't
quite
as
good
as
these
numbers
would
lead
you
to
believe,
because
it
turns
out
that
there's
a
really
expensive
setup
step
that
has
to
be
done
for
each
file
in
the
sources
so
for
each
file
in
the
rows
and
each
file
in
the
columns,
and
so
it
turns
out
whether
that
number
of
rows
is
one
or
20
or
30.
It
doesn't
matter
a
whole
lot.
The
number
actually
has
to
be
fairly
big
before
the
Matrix
computation
costs.
A
So
the
question
comes
up.
Can
I
somehow
identify
likely
renamed
pairs
without
doing
that
full
Matrix
similarities,
I'll
start
by
first
changing
the
file
names
a
little
bit
to
match
my
case
a
little
bit
better
and
then
basically
have
to
look
at
it
as
saying
I,
don't
have
that
Matrix
of
similarity
percentages,
I,
don't
know
anything
about
these
file.
Contents
can
I,
somehow
still
guess
what
is
a
likely
rename
and
after
I
solved.
A
A
Okay-
and
this
really
mattered
in
my
case
because
I'm
like
I,
know,
I
can
see
in
my
file
list
that
I
have
a
file
with
the
same
base
name
on
both
sides.
Why
do
I
have
to
compare
this
one
file
to
5200
files
when,
without
even
opening
the
file
in
the
editor
I'm?
Pretty
sure
that
it's
that's
the
one?
That's
the
rename
and
that
may
sound
like
cheating
and
I
was
worried
that
I
was
cheating,
so
I
went
and
gathered
a
bunch
of
statistics.
A
I
went
and
looked
at
existing
repositories
and
said:
how
often
is
it
the
historical
renames
in
these
existing
repositories
just
to
move
to
file
into
a
different
directory
without
changing
the
base?
Name
and
I
expected
to
happen
some
of
the
time,
but
I
was
surprised
just
how
frequent
it
was,
and
it
also
seemed
to
me
that
the
bigger
repositories
tended
to
do
this
even
more
often,
the
bigger
repositories
are
also
ones
where
the
rename
detection
is
going
to
be
even
more
expensive.
A
So
that
gave
me
the
simple
idea:
let's
go
for
it.
Let's
check
if
files
with
the
same
base
name
are
similar,
so
I
know
they
have
the
same
base:
name
I'm
just
going
to
compare
those
ones
first,
if
they
have
a
high
enough
similarity
where
I'll
require
a
higher
threshold
than
I
normally
do
then
I'll
count
them
as
renames
without
comparing
them
to
everything
else
in
The,
Matrix.
A
If
you
have
a
file
that
could
have
matched
a
file
with
a
different
base
name
and
that
would
have
been
a
better
match,
you
won't
see
it
because
you
first
matched
up
with
a
file
that
happened
to
have
the
same
base,
name
that
it
was
similar
enough
to
We've
documented
that
difference.
We
also
provided
an
ability
for
people
to
be
able
to
test
this
out
and
control.
How
much
additional
similarity
is
required
with
an
environment
variable
called
git
base,
name
Factor.
A
We
didn't
think
to
document
it,
though
so
another
opportunity
for
you
to
get
involved,
but
one
benefit
that
came
with
this.
Actually,
that
might
give
you
a
little
bit
more
comfort
with
this
change
is
that
we
didn't
implement
it
in
the
merge
layer.
We
implemented
it
in
the
diff
layer
and
what
that
means
is
it
doesn't
just
affect
the
new
merge
algorithm.
It
affects
the
old
merge
algorithm
and
it
affects
any
diff
that
you
compute,
which
means
that
you've
already
been
using
it
and
all
get
really
systems
get
231.
A
It's
simple
idea.
It
would
be
really
nice,
but
unfortunately
it
breaks
rename
detection,
not
just
directory
name
detection,
but
regular,
rename
detection
pretty
badly
and
in
fact,
I
had
thought
about
this.
Before
my
talk
two
and
a
half
years
ago,
but
I
thought
it
just
wouldn't
work,
it
would
break
things
but
I
discovered
since
then
how
to
get
it
to
work
and
there
were
a
few
keys
to
unlocking
it.
A
First
of
all,
if
you
could
somehow
know
before
you
started
that
there
weren't
any
renames,
then
this
optimization
is
safe
to
do
and
now,
if
you
start
combining
that
and
think
a
little
bit
further
and
combine
it
with
some
of
my
earlier
optimizations,
you
can
dig
in
a
little
bit
further
and
say
you
know
what
if
there
aren't
any
relevant,
oh
before
I,
get
into
that
the
problem
with
the
first
one.
If
there
are
no
renames,
then
the
optimization
is
safe.
A
There's
no
way
to
know
if
there
are
renames
without
recursing
into
those
trees,
so
it
doesn't
actually
help
you.
But
if
you
go
a
little
bit
further,
you
can
find
out.
If
there
are
no
relevant
renames,
then
you
can
do
the
optimization
and
that
one's
a
lot
more
helpful
because
you
can
find
out
if
there
are
any
relevant
renames
without
recursing
into
those
trees.
A
So
basic
trick.
Is
you
defer
recurring
into
those
trees
until
you
find
out,
if
there's
a
relevant
rename
anywhere
in
your
entire
tree?
If
there
are
any
relevant
renames
anywhere,
then
you
have
to
recurse
into
all
of
those
trees.
But
if
there
aren't
any,
then
you
can
avoid
recursing
into
all
of
them.
A
If
you
implement
this
optimization
turn
off
all
the
other
ones,
then
you
get
a
speed
up
factor
of
4.6,
at
least
for
my
test
cases,
and
it
doesn't
provide
any
behavioral
changes.
But
of
course
one
thing
is
I've
kind
of
relied
on
the
idea
of
relevant
renames
here,
just
in
order
to
be
able
to
implement
this
optimization.
A
So
now,
if
we
combine
all
these
I
can
put
them
together
and
I
get
a
whole
bunch
of
optimizations
and
some
speed
UPS
from
those.
But
the
overall
speed
up
is
not
the
product
of
these
speed.
Ups
you'll
notice,
several
times
I
mentioned.
If
you
turn
off
all
the
other
optimizations
and
run
just
this
one,
because
it
turns
out
there's
a
lot
of
cases
where
multiple
optimizations
could
apply,
and
you
can
only
pick
the
best
one
and
then
the
other
ones
cannot
be
applied.
A
But
one
nice
thing
about
that
is
a
lot
of
these
have
special
cases
where
they
apply.
So
that
means
that
even
if
one
of
them
doesn't
help
you
another
one
might
be
able
to-
and
this
is
very
much
a
case
of
your
results-
will
vary
my
test
cases.
Two
of
them
had
a
huge
number
of
renames
tens
of
thousands,
because
that
was
mimicking
what
was
happening
inside
one
of
the
repositories
of
Interest.
You
probably
have
cases
with
far
fewer
renames,
in
which
case
the
first
four
optimizations
won't
benefit
you
quite
as
much.
A
A
some
of
these
optimizations.
They
also
depend
a
little
bit
on
cases
like
the
caching
renames
only
helps
out
for
rebases
and
Cherry
picks,
where
you're
doing
more
than
one
commit
and
there's
two
optimizations,
the
no
copy
detection
and
the
base
name,
guided
detection
that
actually
help
for
things
other
than
merges
like
diffs.
A
One
other
thing
you'll
note
here
is
that
some
people
are
testing
out
the
new
merge
back
end
like,
for
example,
when
Stoli
had
mentioned
numbers
with
modern
repositories.
He
compared
cases
where
there
hadn't
been
any
rename
detection
involved,
which
meant
that
he
was
only
testing
the
final
optimization.
A
A
Do
it
and
you'll
see
that,
even
in
my
test
cases,
the
speed
up
factors
varied
quite
dramatically
if
you're
curious
for
more
details
about
the
optimizations
involved
here
and
some
that
I
didn't
even
cover,
I've
got
actually
a
six-part
Blog
series
that
you
can
go
read
up
to
learn
more
about
it.
If
you
just
Google
for
optimizing
gets
merged
machinery,
but
especially
if
you
can
find
part
six
because
it
has
backlinks
to
all
the
previous
ones,
then
you
can
learn
more
of
these
details.