►
A
Oh,
oh
so
today,
I'm
going
to
be
talking
about
how
we
might
improve
the
flow
of
letting
people
understand
what
rules
are
associated
to
a
specific
Branch.
So
particularly
this
idea
of
a
deep
linking
to
the
branch
rule
to
explain
that.
Okay,
this
Branch
rule
defines
the
settings
for
this
branch.
A
One
problem
with
that
is
that
the
way
Branch
rules
are
calculated.
There
might
not
be
just
one
branch
rule
per
branch
that
could
be
multiple
branches
and
we
currently
have
a
logic
in
the
back
end.
That
calculates
all
of
the
different
settings
that
we
so
Bridge
protections
and
merge
Quest
approvals
and
then
that
kind
of
forms
what
the
end
settings
would
be.
So
that's
documented
here
where
at
the
moment,
the
most
permissive
rules
carry
through.
A
So
in
this
scenario
here,
if
I
have
a
merge,
rule
and
I
have
one
wild
card
and
one's
specific
and
I
say
the
specific
one.
Is
the
maintainer,
the
most
permissive
rule
when
so
for
this
protective
Branch?
A
So
what
I
am
proposing
is
that
we
we
show
that
calculation,
so
here
I
have
this
Branch
here.
If
I
click
on
this,
it
displays
the
virtual
settings
and
inside
in
the
top
part
here
it's
like.
Oh,
this
was
calculated
by
three
matching
Branch
rules.
A
I
can
see
the
final
result
of
that
calculation
here,
I
can
understand.
What's
going
on,
you
can
see
that
there's
two
approval
groups
here
and
that's
all
through
the
calculations.
I
don't
have
to
do
any
mental
gymnastics
or
try
to
decipher
protect
the
branches
rules.
We
let
the
sit.
We
have
a
kid
lab
calculate
that
for
our
users
we
can
click
on
here
to
see.
Okay,
these
are
the
matching
Branch
rules
that
apply
to
this
specific
Branch.
So
it's
the
Wild
Card
one,
this
specific
one
and
all
branches.
A
So
from
here
we
can,
then
you
can
go
to
edit
and
jump
into
the
specific
Branch
rules
to
then
make
any
changes.
Based
on
that.
The
reason
why
this
is
important
is
because,
right
now
this
is
our
current
flow,
the
user,
maybe
I'm
just
going
to
zoom
in
to
make
it
a
little
bit
clearer.
So
right
now,
I
could
be
setting
up
a
protective
Branch.
A
I
have
a
wild
card
right
now,
and
I
want
to
have
rules
that
are
more
specific
for
a
specific
Branch,
so
I
set
maintainers
and,
as
we
know
from
previously
I
said
the
most
permissive
rule
of
wins
so
I'm
setting
this
up
and
that
looks
good
to
me.
I
go
to
merge,
request
approvals,
I
create
a
new
merge,
request,
approval
specific
to
this
one
branch
here
and
at
this
moment,
I'm
still
in
settings
and
I
have
no
idea
what
the
final
outcome
of
how
many
approvers
groups
will
be
assigned
to
this.
A
What
kind
of
push
rules
will
be
assigned
to
this
I
would
have
to
read
the
docs
and
understand
how
gitlab
calculates
all
of
this
to
get
this
answer
right
now
in
our
products
we
don't
have
a
way
to
visualize
that
within
settings,
but
we
do
visualize
it
once
you
create
an
MR.
So
let's
say
I
create
a
merge.
Quest
on
this
specific
branch.
A
Is
this
area
here
within
Repository?
But
the
path
to
this
all
also
exists
in
settings
because
within
Branch
rules,
let's
say:
I
was
looking
at
this
wildcard
one
here.
If
I
click
on
that
there's
four
matching
branches
and
what
we're
doing
right
now
for
branch
rules
is
actually
linking
this
to
branches
with
a
filter.
So
potentially
these
filtered
branches.
For
that
one
Wild
Card
rule
clicking
on
this,
we
could
display
the
specific
rules.
A
This
is
one
way
we
could
achieve
this
functionality
through
iteration,
and
then
we
can
start
thinking
about
you
know
how
might
we
bring
that
back
into
settings
so
that
you
can
view
those
kind
of
rules
at
this
level
too?
So,
potentially,
you
can
click
here
to
see
what
the
rules
resolve
to
for
this
specific
Branch
or
this
specific
Branch,
but
that's
something
that
I'm
happy
to
get
some
feedback
on
and
yeah.
We
can
move
from
there.