►
From YouTube: GitLab 12.9 Kickoff - Create:Source Code
Description
Track what else is in store for Source Code in 12.9 via our planning issue for the release: https://gitlab.com/gitlab-org/create-stage/issues/65
A
The
software
groups
got
a
lot
of
work
plan
for
the
upcoming
release
from
performance
improvements
to
security
fixes
fixes,
but
I've
also
got
some
great
features
and
improvements
coming
as
well
and
I'd
like
to
highlight
particularly
two
of
these,
the
first
of
which
is
commenting
on
mer
directives.
This
continues
a
significant
body
of
work
that
we've
been
looking
at
over
the
past
few
releases
called
mo
directives.
We've
built
we've
implemented
merger
F
support
for
CI
pipelines,
so
you've
probably
been
using
that
feature
and
in
12.8
the
release.
A
That's
just
about
to
ship
on
the
22nd
of
February
we're
adding
the
first
experimental
support
former
directives,
med
requests.
So
what?
What
is
this?
All
about?
A
merger
if,
if
is
really
trying
to
yes,
provide
a
better
diff
when
you're,
comparing
your
feature,
branch
against
the
target
branch,
typically
master
or
develop,
and
there's
one
specific
edge
case
that
happens
quite
frequently
where
the
diff
can
be
quite
misleading,
and
that
situation
is
where
your
feature
branch
contains
changes
that
have
already
been
merged
into
the
master.
A
So
your
your
branch
is
taking
like
a
couple
of
days,
maybe
a
week
or
two,
and
you
merge
in
the
master
branch
into
your
feature
branch.
Probably
this
is
that
when
you
compare
the
two
branches,
you'll
see
the
changes
that
are
already
in
master
in
the
diff
on
your
feature
branch.
So
it's
confusing,
because
the
diff
contains
changes
that
aren't
really
in
your
merge
request
and
that's
because
we
use
the
three
dots
tumor
to
compare
between
the
merge
base
of
master
and
the
feature
branch
to
the
tip
of
the
feature
branch.
A
So
that
the
background
to
the
situation
when
this
confusing
differ
results
in
12.8,
we
implemented
where
we
are
implementing
this
first
version
of
this
new
DIF
mode.
It's
not
the
default
mode
and
it
doesn't
support
commenting,
and
so
the
important
work
we're
doing
in
12.9
to
start
bringing
this
to
customers,
so
they
can
actually
use
it
in
real
life
is
to
add
commenting
support.
A
So
this
is
a
really
big
improvement
for
diffs
and
their
accuracy,
making
sure
that
the
dips
are
concise,
clear
and
accurate
in
all
situations,
particularly
because
merge
requests
code
review
in
merge
requests
is
a
expensive
process.
It
requires
a
lot
of
time
and
energy,
so
we
want
to
make
it
as
efficient
and
easy
as
possible
for
everyone
involved.
A
The
other
feature
I
want
to
draw
your
attention
to
is
not
adding
approvers
as
participants
of
merge
requests.
So
if
you
use
email
notifications,
you
may
have
noticed
that
when
you're
an
approver
like
your
added
through
the
project
settings
as
an
approver
for
a
merge
request,
then
you
will
be
notified
of
every
merge.
Request
and
you'll
be
more
notified
of
every
single
comment
on
that
merge
request
and
in
the
case
of
most
projects
that
is
completely
unnecessary
and
not
the
expected
behavior.
A
This
seems
much
more
consistent
with
the
way
people
are
expecting
to
receive
notifications
and
should
really
free
up
the
inbox
of
a
lot
of
people
who
are
having
it
overwhelmed
by
email
notifications
that
aren't
helpful.
So
these
are
two
really
exciting
improvements
that
source-code
groups
can
be
working
on
and
you
can
follow
along
on
these
issues.
Leave
your
comments.
Leave
your
feedback
and
I'll,
see
you
again.
Next
month
in
the
12.10,
kickoff
have
a
great
day.