►
A
Hello,
my
name
is
Michael
Lee
of
the
source
code
group
and
today,
I
want
to
talk
about
some
design,
thoughts
and
decisions
around
what
we're
going
to
do
with
this
merge
label
on
branches.
So,
just
as
for
a
background
contacts
in
the
past
with
branches,
we
used
to
have
something
like
this,
where
we
would
list
all
the
branches
and
we
would
have
a
button
to
create
a
new
merge
request
and
if
a
branch
was
merged,
we'll
be
a
merge
request
or
a
branch
using
get
commands
directly.
A
They
would
have
this
purge
label,
and
recently
we
made
this
change
to
remove
that
label
in
favor
of
servicing.
The
correct
state
of
the
merge
requests
itself
on
the
right
hand
side.
So
in
this
case
here
this
branch
has
been
merged
with
the
merger
plus
one
two,
three
four
five,
but
this
feature
Branch
here
could
have
been
merged
manually
using
command
lines,
but
there's
no
label
here-
and
this
has
come
up
in
the
scenario
of
the
delete
merged
branches
functionality
where
both
of
these
branches
would
be
deleted.
A
But
it's
not
very
clear
that
this
would
be
deleted
because
there's
no
label
there.
So
the
question
is:
should
we
bring
back
the
label
if
we
brought
back
the
label?
It
would
look
something
like
this
right,
so
we
have
a
state
here
where
it's
merged,
with
a
merge
request.
That's
obvious-
and
in
this
case
here
this
Branch
would
also
be
labeled
merged,
because
it
is
all
its
changes
have
been
committed
and
the
default
branch
has
this.
A
A
The
interesting
part
with
this
logic
is
that
if
I
created
a
merge
quiz,
if
I
created
a
branch
and
I
left
the
branch
for
a
while
and
there's
new
changes
on
the
default
Branch,
so
that
means
the
default
branch
is
now
ahead
in
my
Branch
itself
is
behind
the
nt4
branch,
so
I'm
behind
one
commit
here.
This
calculation
would
determine
that
this
branch
has
been
in
fact
emerged
despite
the
fact
that
I
did
not
create
any
commits
or
do
anything
with
the
branch.
A
A
There
could
be
work
here
that
was
planning
to
start
and
then
work
on,
but
it
would
be
deleted
and
I'll
be
wondering
why,
when
looking
at
the
merge
table-
and
one
thing
that
should
be
highlighted-
is
that
key
field
to
look
at
here
potentially
is
the
commits
ahead.
So
in
this
scenario,
three
of
these
branches
are
all
zero
and
all
them
are
represent
different
states.
A
One
idea
we
have
was
to
surface
all
the
branches
that
would
be
deleted,
and
but
that's
can
be
hard
to
detect
to
do
the
calculation
on
every
single
branch
on
large
repositories.
So
we
opted
to
go
with
a
simpler
approach
to
say
that
we're
going
to
delete
everything
and
yeah,
you
can't
see
what's
going
to
be
deleted,
and
you
just
saw
hope
that
it's
going
to
be
all
the
branches
you
want
and
not
a
branch
with
an
empty
diff
right.
A
A
So
if
I
went
ahead
and
selected
commit
to
head
as
well
changes
the
order
from
descending
to
ascending,
we
can
actually
isolate
all
the
branches
that
have
zero
commits
ahead.
So
that's
that's
good
for
those
trying
to
manage
their
branches
and
to
see
what
branches
have
been
up
to
date,
all
merged
or
changed
have
all
changes
in
the
default
Branch
but
haven't
been
deleted.
A
So
I
have
all
these
three
branches
here.
One
two
three
and
the
next
thing
that
we
can
introduce
is
delete
multiple
branches,
I'll
click
on
that
invokes
a
view
that
allows
you
to
select
model
one
or
more
branches.
Then
this
scenario
here
what
we
want
to
do
is
just
ensure
that
all
these
things
are
disabled
so
that
we
can't
change
the
list.
But
here
I
can
select
one
too,
because
I
don't
want
to
delete
my
empty
bridge,
and
this
gives
you
the
control.
That
would
be
useful
to
manage
bulk
actions
with
confidence.
A
So
we
can
have
one
two
branches
selected
here
and
if
I
click
delete
branches
here
we
have
all
the
references
and
the
branches.
So
potentially
we
could
surface
them
in
the
model.
It
is
paginated
and
this
view
would
stay
there.
So
the
idea
that
the
context
would
be
maintained,
so
we
can
add
more
to
this
list
and
once
that's
deleted,
we
go
back
into
this
state
here.
A
Let's
see
how
we
have,
whether
we
go
back
to
the
state
or
the
statement,
zero
selected
branches
and
you
have
to
click
X
to
close
that
detail
that
we
can
find
over
time.
But
this
hopefully
gives
you
an
idea
of
how
we
might
be
able
to
deal
with
the
empty
diff
as
well
as
merged
with
the
kit
commands
or
merge
requests
and
generally
more
control
over
our
branches.
A
One
observation
from
here
is
that
now
we're
adding
a
lot
more
to
the
top
area
here,
I
think
this
can
live,
as
is
for
now
for
large
screens,
but
smaller
screens
it's
going
to
get
really
tight.
So
there
is
a
piece
of
work,
that's
being
explored
where
it's
taking
a
look
at
restructuring
the
branches
page
to
use
patterns
around
filtering
and
sorting
that
are
established
in
other
areas,
such
as
merge
requests
and
issues,
and
here
is
an
example
of
how
that
might
look
like.
We
have
our
branches
here.
A
The
overview
currently
just
shows
active
and
Stillness.
So
if
we
default
to
active
branches,
we
could
potentially
not
have
to
retrieve
this
Dale
branches
all
the
time
and
to
access
that
you
can
just
quickly
go
through
the
drop
down
to
select
it.
It
is
an
extra
click
to
get
to
the
scale,
but
this
pattern
allows
us
to
enhance
more
functionality
with
our
branches,
such
as
filtering
on
your
branches,
which
is
something
that
has
come
up
in
the
past.