►
From YouTube: Merge Trains support for fast forward merge
Description
CI team discussion on 2020-11-17 about work required for merge trains to support fast-forward merge.
A
Hey
team
welcome
to
our
sink
about
merge
chain
support
for
fast
forward,
merge.
A
couple
things
that
I
want
to
get
out
of
this
session
is
an
understanding
of
how
we
would
break
up
this
work.
We
have
some
placeholder
issues
that
litika
and
I
talked
about
and
she
created
it
under
the
original.
We
elevated
the
original
issue
as
an
epic
and
have
issues
under
that,
and
I
just
want
to
make
kind
of
revisits
what
shinya's
estimate
was
and
what
the
works
to
be
done.
A
A
Obviously,
we
needed
to
have
the
discussion
before
even
considering
it
for
a
milestone,
but
I'm
hoping
that
if
we
break
this
work
up
and
do
some,
let's
say
we
decided
to
do
some
of
the
front
end
work
for
changes
to
the
copy
on
some
existing
fields
and
we
have
it
behind
a
feature
flag
until
everything
can
be
delivered.
I
would
be
happy
with
that
to
get
started
on
something
in
the
next
milestone.
So
take
a
look
there.
A
A
B
A
B
A
So
this
issue
as
originally
written
I
should
I
think
they
were
going
to
tackle
it
as
a
front-end
thing,
but
based
on
his
comment,
there
he's
suggesting
the
back
end.
Work
would
be
autumn
making
the
rebase
automatic,
and
maybe
I
should
take
a
step
back
at
the
top
of
our
agenda.
I
did
state
what
the
problem
to
solve
is
currently
merge.
Strains
will
drop
a
fast
forward,
mr
that's
been
added,
but
by
the
time
merge
strain
gets
to
it.
A
The
source
branch
cannot
be
fast
forwarded
and
so
then
merge
strain
doesn't
automatically
rebase.
It
will
drop
that
fast
forward,
mr,
which
means
that
requires
manual
rebase
of
the
dropped,
mr
and
then
re-adding
it
to
merge
strains.
We
would
like
merge
trains
to
handle
that
automatically
the
rebase,
so
that
in
and
of
itself
would
require
some
back-end
work.
A
Now
there
would
be
front-end
work
of
some
of
the
messaging
that
has
to
change
in
the
system
like,
for
example,
instead
of
saying
this
is
dropped
because
it
can't
be
fast
forward
it,
it
may
say:
either
the
application
is
successfully
rebased
or
the
application
was
not
able
to
rebase
and
then
drop
it.
So
that's
an
example
of
some
of
the
front-end
work
in
the
copy
that
has
to
change.
A
If
you
look
at
the
title
of
the
issues
under
this
epic
that
I
linked
to
at
the
top
of
the
agenda,
you
could
see
we
have
docs
update
and
then
we
have
two
issues.
Add
system
messages
for
for
mr
page
for
merge,
request
page
for
the
merchant
support,
I
think,
that's
front,
end
update
project
settings
copy,
I
think,
that's
front
end.
A
We
haven't
added
a
a
an
issue
for
the
back
end
work
to
automatically
rebase,
because
I
wasn't
sure
if
that
should
be
its
own
issue,
or
does
it
have
to
be
tied
together
with
system
messages,
because
that
kind
of
is
what's
happening.
We
want
whatever's
happening
automatically
to
also
send
system
message.
I
don't
know.
B
Okay,
yeah,
to
answer
your
question:
yeah
I
mean
if,
as
long
as
we're
working
behind
a
feature
flag,
we
can
go
ahead
and
start
working
on
this.
I
I
mean
his
breakdown
seems
reasonable
to
me.
I
haven't
like
dug
super
deep
into
like
the
nitty-gritty
stuff,
but
yeah.
That
seems
like
a
reasonable
breakdown
approach.
A
I
have
to
I
guess
I
I
need
to
know
what
the
estimate
would
be
for
the
front
end
work
for,
for
that.
So
can
I
peyton
do
you
want
to?
Let
me
check
with
sam.
I
know
we're
past
the
point
where
we're
doing
estimates
for
13.7,
but
I
would
like
to
see
those
two
front-end
issues
for
adding
the
system
messages.
I'm
sorry
for
updating
the
project
settings
copy.
D
I
think
the
this
whole
epic,
it's
very
backhand
heavy
backhand,
because
we
it's
basically
the
fast-forward
marriage.
Is
it's
not
anything
that
we
support,
like,
especially
with
with
merit
training
but
like
the,
I
think
we
have
to
change
a
lot
of
the
logic
underneath
the
merge
train
and
if
we
need
to
memory
to
create
a
different
strategy
that
is
being
used,
because
I
think
the
current
strategy,
or
like
most
of
the
code,
that
we
have
for
with
merge
training
in
terms
of
the
core
logic.
D
D
We
actually
merge
something
with
the
merge
train,
and
so
I'm
wondering
there
if
we
wanted
to
think
about
different
strategy
on
when
something
when
a
merge
request
gets
into
the
train,
we
automatically
might
need
to
rebase
it
as
it
gets
into
the
train
on
a
specific
specific
order.
So
then
we
can
be
confident
that
the
fast-forward
merge
works,
because,
as
of
now,
this
will
bring
the
even
if
we
implement
the
fast-forward
merge
on
the
merge
side
of
the
merge
tray.
D
I
think
this
is
my
understanding
of
the
problem.
I
may
not
be
full
like
clear
with
the
the
way
merge
training
works
like
I
haven't,
looked
at
the
code
in
details,
but
this
is
my
general
kind
of
concerns,
but
I'm
sure,
like
maybe
you
know,
alison
or
for
kind
of
thought
more
deeply
about
that.
I'm
not
sure,
but
we
do.
We
have
the
information
from
xenia,
more
kind
of
more
specific
into
in
terms
of
implementation,
of
what
kind
of
challenges
on
the
back
end
that
this
is
involved.
A
A
D
We
are
moving
the
pointer
of
the
branch
from
one
commit
to
another
one
and
there
is
no
actual
merge
commit.
So
in
that
case,
every
time
the
merged
train
emerges
something
advances
the
target
branch
everything
else
needs
to
be
rebased
again,
even
though
there
might
not
be
marriage
conflicts
if,
by
doing
like
with
a
normal
marriage,.
A
D
A
A
Rebasing,
I
don't
know
where
I
read
it
yeah,
it's
so
under
description,
further
details
in
the
second
paragraph
and
the
last
sentence,
it
does
say
in
order
to
actually
complete
the
merge.
The
merge
train
also
needs
to
rebase
the
entire
feature
branch
and
then
merge,
oh,
but
it
there
was
some
place
where
shinya
actually
says
in
his
comments.
It
was
a
comment
that
said
it
would
require
rebasing
the
train
itself,
all
of
the
subsequent
mr's
in
the
train.
D
So
yeah
this
is
a
different
strategy
of
adding
adding
things
to
the
trade.
So
that
means
that,
with
a
normal
strategy,
we
just
keep
doing
what
we
do.
But
if
you
enable
fast
forward
merge,
you
need
to
use
a
different
strategy
when
adding
something
to
the
train,
so
it
might
mean,
as
you
add
something
to
the
train,
it
will
rebase.
On
top
of
the
previous
changes
on
the
train
and-
and
maybe
if
everything
is,
is
rebased
on
top
of
each
other,
then
it's
all
going
to
be
a
fast
forward,
marriage
possible.
D
But
if,
if
we
don't
rebase,
as
we
add
something
on
the
train,
we
will
have
to
rebase
at
some
point
during
the
merge.
But
at
that
point
we
might
need
to
restart
the
pipeline,
so
it
might
cost
more
because
we
have
to
we
first
try
to
run
the
pipeline.
Then
we
cannot
merge
so
we
have
to
rebase
and
restart
another
pipeline.
So
in
that
case
it
costs
us
double.
D
A
Okay
is:
is
that
something
we
would
want
to
do
all
of
that
back-end
work
before
we
start
any
of
the
front-end,
both
copy
that
explains
the
behavior
on
the
text
on
the
pipeline
settings
page.
Can
that
be
started
or
do
we
want
to
figure
out
all
the
behavior
and
complete
the
back
end
work
before
we
would
know
how
to
describe
it.
A
A
It
says
removal,
but
I
think
it
he
also
means
enabled
and
then
eventually,
removal,
but
then
the
documentation
would
it
help
to
document
how
this
would
work
first
before
we
even
I
know
in
some
cases,
thinking
through
how
the
feature
would
work
and
documenting
it,
even
if
it's
not
published
yet
might
help.
I
don't
know
what
order
it
has
to
happen,
or
is
this
documentation
in
this
case
has
to
happen
after
the
actual
back-end
work
is
done.
E
A
D
D
E
I,
I
think,
that's
a
good
point
fabio.
I
think
it
seems
like
a
lot
of
the
functionality
or
the
the
scope
of
this
feature
is
is
around
like
communication
and
settings
and
and
like
helping
users
understand
what's
happening,
but
if
that,
if
that
core
fast
forward
part
of
it
doesn't
work
or
if
it
doesn't
work,
how
we
think
it's
gonna
work,
then
the
rest
of
it
doesn't
matter.
A
Yeah,
I'm,
I
can
create
an
issue
to
do
a
poc
to
to
confirm
what
we
think,
how
we
think
we
would
approach
it
could
work.
Can
we
would
it?
I
would
like
to
put
this
poc
in
the
next
milestone
so
that
we
make
some
progress
on
this
and
then
I
know
you
said
you
suggested
darby
doing
the
documentation
in
parallel,
but
maybe
we
start
with
that.
A
E
A
A
Spikes
and
poc
is
a
slightly
different.
We,
I
thought
we
normally
time
box
it
to
a
milestone
and
or
but
not
put
a
weight
on
it,
because
it's
kind
of
an
unknown
but
I'll
find
out
from
cheryl
and
attentively
put
in
our
next
milestone
and
see
how
far
we
get
with
this
shinya
is
obviously
a
good
resource
when
you're
doing
the
poc
to
to
work
with
async,
because
he
has
a
lot
of
knowledge
around
this
okay.
Well,
a
couple
of
my
questions
were
answered.
D
Yeah,
I
ask
there's
some
questions
regarding
the
workflows
that
we
have
in
our
issue,
so
the
first
one
was
a
little
open
back,
so
just
to
see
what
the
workflow
was
so
on
the
workflow
one.
We
basically
say
that
the
user
adds
the
mr
to
the
merge
train
and
then
the
merge
training
creates
a
new
pipeline
and
validates
the
mr.
D
So
we
actually
run
the
pipeline
immediately
and
then
we
rebase
on
top
of
the
master
and
then,
if
the
rebate
succeeds,
we
continue
it
fails.
We
pull
that
all
of
the
train,
but
then
so
I'm
not
sure
what
these
will
were
kind
of
old
notes
or
more
kind
of
refined.
My
opinion,
my
question
was
more
about:
do
we
run
a
pipeline
immediately
before
doing
a
remember,
a
rebase
or
what
was
the
advantage
of
that.
C
A
A
E
D
E
A
A
A
A
D
So
I
think,
basically,
that
the
workflow
one
is
somehow
the
way
the
train
works
today,
but
with
them
with
the
modification
of
the
the
merge
is
not
like
a
normal
merge,
but
it's
fast
forward.
So
it
requires
a
rebase.
But
I
think
in
that
case
we
might
need
to
rebase
first
and
then
run
a
pipeline.
So
maya
need
to
swap
the
three
and
two.
A
D
D
D
But
as
you
rebase
a
master,
you
push
your
changes.
A
new
pipeline
will
start,
so
you
have
to
wait
until
the
pipeline
finishes
before
you
can
actually
merge,
but
because
we
have
a
running
trade.
That
means
in
the
meantime,
while
the
pipeline,
your
pipeline
runs
and
you're
waiting
to
click,
then
merge
immediately.
D
The
merge
train
might
actually
merge
something
in
the
meantime,
which
will
invalidate
your
rebase
and
and
then
you
are
stock.
Basically
you
to
try
to
rebase
your
merge
request
all
the
time,
but
you
are
actually
not
doing
anything
because
the
merge
and
as
long
as
the
merge
train
runs
as
emerging
things,
you
are
not
able
to
measure
anything
immediately
and
because
of
the
fast
forward
marriage,
and
so
that
basically
invalidates
everything
after
as
soon
as
something
is
merged
by
the
merit
train,
it
automatically
invalidates
everything
else.
D
So
I
was
wondering
she
instead
of
merge
immediately.
She
would
consider
doing
something
like
a
ad
on
top
of
the
train,
which
will
be
the
equivalent
of
merge
immediately,
but
the
the
mr
sudden
at
the
very
top,
the
on
the
train.
The
merge
train
is
recalculated
once
and
then
you
don't
you
as
author
of
the
merger,
because
you
don't
have
to
deal
with
investing
anything.
You
just
add
something
on
the
top
of
the
train.
A
A
On
the
one
hand,
I
I
think
I
want
to
desculp
that
from
this
work
as
long
as
we
can
confirm
that
we
aren't,
I
think
the
thought
there
was
don't
break
merge
immediately,
but
there's
conflicting
functionality
there.
As
far
as
I
mean,
merge
immediately
basically
bypass
merge
strains,
and
whenever
that
happened,
it
would
crop
cause
everything
to
have
to
be
rebased
right,
because
it.
D
Yes,
this
is
one
problem,
but
the
other
problem
is
that,
even
if
you
don't
have
merge
trains
and
if
you
want
to
merge
immediately
because
on
your
project,
you
have
set
fast
forward
merge,
you
can
only
merge
if
you
have
rebates
on
top
of
master.
There
is
nothing
else
merged.
In
the
meantime,
they
have
a
clean
rebase
on
top
of
master.
So.
C
D
That
case
you
can
push,
you
can
actually
merge
it,
but
after
you
rebase
there
might
be
the
train.
The
train
might
actually
merge
other
things
which
invalidates
the
overbase,
and
this
is
a
kind
of
workflow
to
point
number
four.
Basically,
this
in
this
case,
like
you
as
a
author,
might
be
stopping
that
looper,
but
you
actually
can't
merge
immediately.
D
F
D
Yes,
and
no,
so
we
so
if
you
merge
immediately
so
if
you
want
to
merge
immediately
you,
you
wait
for
the
pipeline
to
passes
and
then
to
merge
immediately,
actually
allows
you
to
to
merge
immediately.
Then
the
train
is
going
to
be
stopped
and
recalculated
back
right,
but
with
with
the
fast
forward,
merge
you
can't.
D
F
D
D
But
if,
if
you're
not
fast
enough
because
after
maybe
you
want
to
wait
for
the
pipeline
to
pass
and
the
merge
training
is
invalidating
your
rebase
all
the
time,
then
you
need
to
rebase
again
and
wait
for
another
pipeline.
And
then
the
merge
train
keeps
validating
that.
You
know
unless
you
have
to
stop
the
train
and
then
merge
everything.
D
No
problem,
I
think
it's
just
a
specific
problem
of
fast
forward,
merge
that
makes
things
more
complicated
because
it's
it's.
It's
like
having
two
different
types
of
match.
Trade
like
fast
forward
merge
is
a
sort
of
lock
on
the
on
the
target
branch
and
the
train.
Is
it
works
the
same
way,
so
the
two
things
actually
are
conflicting
with
each
other.
D
A
A
And
it
would
trigger
the
re-calculating
of
everything
else
in
the
train
in
the
way
that
it
normally
works,
but
that
would
be
something
I
think
would
be
an
additional
issue
of
create
for
that.
As
far
as
approaching
it,
it's
really
changing
the
behavior
of
merge
immediately
in
the
context
of
a
running,
merge
strain,
as
opposed
to
specific
to
this
topic
of
supporting
fast
forward
merge.
A
D
I
think,
even
if
we
do
in
a
separate
issue
that
still
needs
to
be
there
when
we
enable
the
feature
flag,
because
when
you
enable
merge
train,
you
still
want
to
have
the
ability
to
merge
something
immediately.
If
some
urgent
thing
happen,
without
that
you,
then
you
won't
have
the
ability
to
add
to
merge
something
immediately.
So
you
always
have
to
wait
on
on
the
marriage
train.
D
A
Okay,
I'm
not
that
clear
that
those
are
mutually
exclusive,
because
I'm
not
that
familiar
with
merge
strain
okay.
I
have
to
go
look
at
that,
in
which
case
it's
fine
I'll
make
that
issue
as
part
of
this
epic,
but
just
to
make
sure
I
understand
correctly
fabio.
What
we're
saying
is
we
would
the
change
with
the
behavior
change
would
be
that
when
they
click
merge
immediately.
A
A
D
G
Yeah,
I
just
wanted
to
ask
a
quick
question.
Maybe
this
is
me
lacking
context
to
unfast
forward
merges
but
fabio
in
your
scenario,
if
you
want
to
merge
immediately
when
a
train
is
running,
and
then
that
puts
your
mr
in
position
one,
could
it
potentially
invalidate
any
of
the
ones?
Mrs
currently,
on
the
train?
D
Yeah
so
when
I
think
these
are
also
happened
today,
so
if
you
want
to
merge
something
immediately,
invalidates
the
train
and
then
the
train
is
to
be
recreated,
and
this
is
expected
because
you're
just
putting
something
on
top
of
everything
else.
So
all
the
changes
will
need
to
be
either
rebased
or
need
to
be
recalculated
on
top
of
each
other,
and
I
think
this
is
expected.
D
Well,
you
can
merge
immediately
if
you're
fast
enough,
but
you
have
always
this
kind
of
race
condition
that
I
think
we
should
not
expose
to
the
to
the
end
user.
I
should
be
something
like
I
want
to
merge
this
immediately,
but
maybe
for
maybe
we
can
still
call
it
merge
immediately,
but
then
under
under
the
hood,
we
added
on
position
one
of
the
trains,
so
something
is
slightly
different,
but
for
the
user
it
looks
like
the
same
thing,
I'm
not
sure.
Maybe
it
makes
sense
to
be
explicit
or
maybe
not.
D
Sure,
but
it's
interesting
because
you
you
want
to
merge
immediately,
but
you
might
not
be
able
to
merge
immediately
because
the
master
keeps
changing
all
the
time
this.
This
may
be
totally
fine.
Your
repos
they're,
very,
like
low
traffic,
but
in
you
know,
meet
lab.com.
I
I
think,
like
I
will
github
or
projects.
I
think
it
will
be
very,
very.
D
A
In
addition,
I'm
going
to
work
on
the
documentation
on
this
describing
what
behavior
we
want
for
this
feature.
Maybe
a
first
draft
with
the
tech
writer's
help
and
then
we
will
have.
We
could
have
everyone
work,
help
with
that
async
and
then
once
we
have
that
clear,
maybe
the
following
the
future
upcoming
milestones.
We
can
start
implementing
the
front
end
changes
as
well
as
the
actual
logic
to
to
do
the
automatic
rebase
of
a
password
merge.
A
G
A
We
it
might
benefit
us,
whoever
out
whoever
works
on
this
spike,
to
to
leverage
shinya's
knowledge
on
on
merge
strain
as
well.
I
think
he
had
a
clear
idea
on
how
to
implement
this.
He
just
didn't
the
exchange,
hands
and
groups
before
they
could
take
it
on
all
right.
Folks,
give
you
back
15-20
minutes
of
your
day.