►
Description
Source Code:
- https://gitlab.com/gitlab-org/gitlab/issues/27008
- https://gitlab.com/gitlab-org/gitlab/issues/460
- https://gitlab.com/gitlab-org/gitlab/issues/196514
Gitaly:
- https://gitlab.com/gitlab-org/gitaly/issues/1519
- https://gitlab.com/groups/gitlab-org/-/epics/842
Gitter:
- https://gitlab.com/gitlab-org/gitter/webapp/issues/2394
- https://gitlab.com/gitlab-org/gitter/webapp/issues/2411
A
So
the
first
feature
I've
got
to
share
something
that
I
mentioned
last
month
in
the
12.7
kickoff,
and
it's
a
new
merge,
ref
based
gift
mode
for
merge,
request
comparison
and
the
reason
this
is
important
is
that
when
you've
working
on
a
feature
branch
for
example-
and
it
falls
behind
the
master
branch,
so
you're
working
on
a
feature
for
a
couple
of
days-
and
you
want
to
bring
the
latest
changes
from
the
master
branch
into
your
feature
branch.
If
you
would
emerge
those
in
rather
than
rebasing.
Next
time
you
push
to
get
lab.
A
Your
diff
is
going
to
show
a
lot
of
confusing
things
because
it's
going
to
show
those
changes
and
pulled
for
a
master,
and
the
reason
is
that
we
use
the
git
diff
command
as
written
here.
Comparing
the
target
and
source
which
compares
using
the
merge
base,
which
is
the
common
ancestor
of
those
two
branches,
and
so
that
creates
some
confusion,
because
really
there
are
changes
showing
your
diff
that
are
already
in
the
target
branch.
So
that's
not
very
helpful.
A
A
But
all
going
to
plan
you'll
be
able
to
see
this
new
mode
as
a
drop-down
when
you're
viewing
your
diff
you'll
be
able
to
select
between
master
head
and
master
default,
the
current
mode.
So
this
is
a
really
exciting
improvement
and
unfortunately,
we
couldn't
start
over
in
12.7,
because
we
ended
being
blocked
by
preparation,
work
that
didn't
ship
in
time.
So
this
is
an
exciting
improvement
that
we
hope
to
come
in
twelve,
eight
to
all
versions
of
get
lab.
A
The
next
item
is
something
I
also
mentioned
in
the
previous
12.7
kickoff
call
that
the
source
code
group
will
be
working
on,
which
is
scoping,
merge,
request,
approvals
to
protected
branches
when
you
configure
approval
rules
for
a
merge
request.
These
apply
to
every
single
merge
request
without
exception.
So
if
you
need
a
security
person
to
review
each
merge
request
a
couple
of
maintain
ins,
maybe
some
other
sign-off
process.
Every
single
merge
request
has
to
satisfy
those
requirements,
and
sometimes
that's
good,
but
sometimes
it's
not
really
ideal.
A
Perhaps
if
I'm
merging
from
my
own
feature
branch
into
a
colleague's
feature
branch,
because
we're
working
on
the
backend
and
front-end
of
the
same
feature,
and
we
want
to
work
on
two
different
branches
that
would
be
really
annoying.
Similarly,
you
might
want
to
actually
have
different
approval
requirements
for
your
master
branch
versus
a
release
branch
because
you
take
you.
Do
your
automated
release
process
off
of
your
release
branch.
A
So
you
actually
want
a
release
manager
to
review
changes
that
come
in
from
master
into
the
release
branch,
and
so
we
wanted
to
add
more
flexibility
to
approval
rules
and
we
wanted
to
make
them
less
restrictive
in
the
cases
where
they
don't
need
to
be
as
restrictive,
so
giving
more
flexibility
to
put
the
controls
in
a
more
precise
location.
And
so
what
this
will
mean
is
when
you're
configuring
an
approval
rule
you
can
now
specify
for
which
target
branches
it
will
apply
either
a
named
branch
or
using
a
pattern.
A
So
just
the
same
as
you
would
selecting
a
protected
branch
and
rule
when
configuring
those.
So
this
is
a
really
nice
improvement.
We've
actually
already
finished
the
back
end
because,
as
I
said,
we
were
working
on
it
in
the
12th
or
cellar
seven
development
cycle,
but
we're
still
finishing
off
the
final
touches
on
it
in
12.8.
So
we're
very
excited
to
this
feature
and
know
that
it'll
help
a
lot
of
customers
with
merge
request
approval
process.
A
The
next
item,
I'd,
like
to
share
from
the
source-code
group,
is
a
proof
of
concept,
so
this
isn't
going
to
be
something
that
you'll
actually
get
to
use
at
the
end
of
12.8,
but
I
think
it's
very
exciting,
we're
doing
a
spike
in
to
understand
to
adding
simple
documentation
and
jump
to
definition
in
the
blog
view.
So
this
is
similar
to
the
source
graph
integration,
but
we're
looking
to
try
and
make
some
of
those
features
available
to
all
projects.
A
Public
projects
on
gearlive.com,
private
projects,
on
gilt,
lab,
comm
and
also
self
hosted
get
lab
instances.
We
think
this
is
a
really
great
feature
and,
and
so
we're
doing,
some
experimentation
building
this
proof
of
concept
to
better
understand
the
technical
challenges
in
building
is
in
to
get
web
natively
and
offering
this
to
everyone
so
watch.
This
space
will
certainly
update
you
in
future.
Kickoff
calls
on
where
these
features
going
and
plans
here
that
I
wanted
to
share
this
very
exciting
project
with
you.
A
A
This
is
really
important
for
a
lot
of
gitlab
servers
where
there's
heavy
CI
loads,
you
push
a
new
commit
to
get
lab
and
it
suddenly
kicks
off
a
hundred
parallel,
CI
jobs.
It's
really
important
that
this
doesn't
degrade
the
performance
at
the
giddily,
node
and
impact
of
performance
is
get
mobile
application
and
other
projects
on
the
same
server.
A
We
hope
and
finally,
I've
got
two
very
exciting
improvements
coming
in
the
get
er
group
to
the
git
er
application,
the
git
er
application
is
a
great
place
for
you
to
build
a
community
around
an
open-source
project,
particularly
you
can
create
communities
which
is
a
collection
of
rooms,
and
then
each
of
those
chat
rooms
can
relate
to
different
projects.
So
you
can
provide
support
to
people
who
use
your
open
source,
library
or
application.
A
For
example,
that'll
correctly
linked
to
the
issue
inside
of
get
lab,
there's
also
a
bunch
of
other
improvements
that
will
be
working
on
around
users
and
inviting
them
from
get
lab.
The
people
you
collaborate
in
get
lab,
inviting
them
into
your
git
er
channels,
but
yeah.
We're
really
excited
about
improving
the
integration
between
get
lab
and
get
ER
and
there's
more
to
come
in
the
coming
releases
on
this
front.
A
So
I
think
some
wonderful
improvements
coming
in
12.8
very
excited
to
see
these
go
live
so
keep
your
eye
out
for
the
release
post,
which
is
the
actual
confirmation
when
these
things
will
be
ready
to
use
and
try
out
yourself.
But
otherwise,
I'll
speak
to
you
in
a
month
to
the
12
o'clock,
9
kickoff
and
great
day.