►
From YouTube: MT support for FF merge 2020-12-09
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
I'm
sorry,
I
was
running
late
from
a
one-on-one,
hey
folks,
all
right,
thanks
for
joining
for
us
to
think
about
the
discussing
the
merchant
support
for
fast
forward
merge.
B
So
by
the
way,
thank
you
vitica
for
the
latest.
Your
latest
attempt,
as
far
as
cleaning
up
that
that
epic,
to
make
it
clear
what
we're
trying
to
achieve
here
that
the
the
flow
that
you
added
was
amazingly
like
cleared
up
a
lot
of
the
confusion
for
me
as
well.
A
And
it
also
helped
me
understand
that
where
am
I
missing
things
I
mean
the
flow
that
we
have.
It
doesn't
reflect
what
you
want
to
achieve
right
now,
but
it
certainly
tells
me
what
is
it
that
I
was
getting
wrong
all
along
and
maybe
I'm
still
getting
wrong.
So
I
put
my
comments
in
the
figma
file
at
those
particular
positions.
A
B
So
I'm
just
updating
the
agenda
right
now.
What
are
the
first
things
we
wanted
to
discuss?
I
haven't
I
didn't
come
with
with
specific
questions
of
my
own.
A
I
had
a
question,
I
mean
a
very
basic
question
so
when
I
went
to
this
epic,
the
first
paragraph
in
the
problem
to
solve
it
says,
can
I
share
my
screen.
Yes,
yeah.
A
All
right,
so
the
problem
to
solve
it
says
more
strains
could
help
solve
a
fundamental
contention
problem
of
fast
forward
merges
because
the
ci
pipeline
must
be
run
every
time.
The
merge
request
is
rebased,
so
I
figured
that
the
problem
that
we
were
trying
to
solve
here
is
that
maybe,
if
we
allow
fast
forward
merge
in
the
merge
train,
we
wouldn't
have
to
rebase
every
single
time
when
the
master
changes,
which
is
every
single
time,
a
merge
request
is
merged.
A
But
so
I
had
put
that
as
the
hypothesis
in
the
figma
file,
but
I
was
looking
at
fabio's
comment
that
maybe
this
would
not
be
possible
that
I
mean
even.
C
A
C
So
I
was
going
to
say
that
it
requires
you.
It
requires
you
to
rebase
off
of
master
any
time
master
changes
to
do
a
fast-forward
merge,
but
shinya
was
also
recommending
using
not
well
it's
kind
of
weird
because
it's
like
not
actually
a
fast-forward
merge,
but
he
was
recommending
to
build
the
the
result
of
like
the
pre,
the
other,
mrs
and
then
in,
like
a
temporary
ref
and
then
just
kind
of
like
replace
the
ref
on
master
with
that
or
like
use
a
pointer.
C
So
I
don't
know
I
I'm
still
kind
of
like
look.
I
sort
of
wrote
up
a
a
simulation
and
I'm
still
like
kind
of
looking
for
feedback
on
that.
So
we
can
see
as
far
as
that
goes.
D
All
right,
so
what
I
wanted
to
say
with
that
is
so
alison
is
you're.
You're,
definitely
correct
on
that.
So
when
we
can
simply
merge
a
branch
into
master
because
that
will
create
like
a
merge
commit
and
from
fast
forward
merge,
you
don't
want
to
have
a
merge
commit,
and
so
we
have
to
rebase
regardless
now.
The
point
is,
I
think,
from
the
hypothesis.
The
way
I
read
it
was
that
every
time
master
changes
we
have
to
rebuild
the
train
and
we
don't
need
to
rebuild
the
train.
D
I
think
because
we
are
using
the
the
merge
train
reps,
these
temporary
reps,
that
we
are
using
to
to
run
the
pipeline
against
the
diff
of
the
merge
ref.
The
cascading
refs
should
match
the
the
diff
of
them
are
being
rebased
right
before
we
merge
so
because,
basically,
the
previous
ref
will
become
master
eventually
for
the
other
cascading
reps.
So
if,
before
merging
a
ref,
we
rebase,
we
basically
are
applying
the
changes
of
the
feature
branch
on
top
of
the
previous
ref,
which
that
will
be
master
eventually,
so
the
two
diffs
will
match.
D
So
if
we
run
our
pipeline
on
the
merge
request,
merge
train
reps
in.
C
D
D
So,
even
even
if
that's
a
simple
example
of
having
the
commit
message,
commit
notes
and
the
commit
header
and
and
and
body
that
will
be
different,
because
what
we,
the
committee
we
have
on
our
merge,
cascading
ref,
is
actually
a
custom
message
that
says
I'm
testing
this
merge
request
or
for
for
this
merge
train,
and
so
we
are
actually
not
merging
what
the
user
did,
but
we
are
merging
something
that,
with
an
internal
graph
that
we
did
on
on
our
side.
This
would
be
the
downside,
in
my
opinion,
if
we
merge
the
the
internal.
D
So
if,
if
we
merge
or
like
a
change,
the
pointer
to
use
the
internal
ref
rather
than
merge
a
request,
feature
branch
that
will
be
more
efficient,
I
think
internally,
because
we
already
have
all
this
done.
We
don't
have
to
rebase
and
do
anything
else
right.
It
will
be
more
efficient,
but
I
think
we
will
introduce
some
problems
where
the
final
commit
that
you
see
on
master
is
not
what
you
had
in
the
merge
request.
It's
something
internal
that
we
generated,
so
user
might
be
confused.
D
D
D
D
C
D
D
So
when
we
say
these
amara
now
can
be
merged,
because
the
merit
trade
pipeline
passed,
then
we
have
to
rebase
the
feature,
branch
and
merge
immediately
and
now
I'm
not
sure
like
how
expensive
it
is
to
do
the
rebase
server
side,
like
all
the
time
and
like
how
much
do
we
save
from
reusing
the
internal
ref
and
do
this
work
of
replacing
the
commit
where
it's
kind
of
looks
more
efficient,
but
how
efficient
that
watch
will
actually
be.
I'm
not
sure
about
that.
C
Yeah,
I
guess
if
we
do
do
a
rebase
and
merge,
though
I
I
guess
it
could
get
kind
of
messy.
Potentially,
if
you
know
if
the
merge
did
fail
for
for
some
reason.
C
C
I
guess
there's,
I
guess
it
just
seems
simpler,
yeah
to
replace
the
ref,
but
yeah,
I'm
not
sure
if
the
if
customers
will
care,
if
the
comments
are
look
different
than
what's
on
their
branches.
A
So
what
do
you
think
would
it
be
worth
releasing
another
feature:
flag
and
testing
with
users.
A
Yeah
yeah,
because
I
mean
if
we
internally
are
not
very
sure
how
much
of
a
difference
is
it
going
to
make
as
compared
to
the
previous
method.
Yeah-
and
I
mean
with
this
like
the
right-
commit
history
not
being
available
how
much
of
a
difference
that
make
difference
that
makes
for
users
in
their
workflow.
B
Are
you
yes,
so
the
first
part
of
your
question,
I
think
that
would
be
useful
and
helpful
to
to
do
some
some
testing
with
users
for
for
the
solution,
validation.
But
would
we
have
like
a
proof
of
concept
for
them,
or
is
it
just
a
talking
through
the
the
output
to
get
feedback.
C
We
could
probably
provide
an
example
of
what
the
history
would
look
like
for
a
typical
fast-forward
merge
versus
you
know,
kind
of
just
swapping
out
the
ref
of
the
merge
train.
B
That
probably
would
be
good.
We
could
limit
it
to
that
to
be
very
specific
and
maybe
vitica
we
can
use
the
the
there
was
training
recently
on
the
new
tool
user
testing.
That
is
an
unmoderated
test
where
we
can
share
it
with
the
users
that
are
very
vocal
on
this
issue
for
fast
forward,
merge
and
merge
trains
and
have
them
go
out
there.
B
I
haven't
looked
at
how
to
configure
that
tool
for
our
we're,
basically
surveying
for
input
right,
but
we
could
do
that
unless
you
wanted
to
have
a
live
discussion
with
them,
but
you
it
would
be
harder
for
you
to
schedule
all
those
it's
up.
We
can
talk
about
that,
but
I'm
in
agreement
with
that,
but
allison's
idea
is
great.
We
can
share
with
them
what
the
history
would
be
like
on
a
regular
fast
forward
and
what
it
would
be
like,
and
what
we're
proposing
and
see
if
it's
problematic.
A
Okay,
another
thing
that
I
wanted
to
speak
about
was
this
option
that
I
this
change
that
I
made.
I
think
fabio
recommended
this,
but
he
sees
some
problem
in
this
workflow
now,
adding
to
the
first
position
in
the
more
strain
instead
of
merging
immediately,
I
mean,
instead
of
providing
the
option
to
emerge
immediately.
D
B
D
I'm
not
sure
if
this
was
a
it's
a
good
idea.
So
if
the
user
wants
to
merge,
manage
requests
immediately,
it's
it's
it's
urgent
that
they
have
to
merge
it
now
right.
So
you
don't
want
to
wait
for
the
merge
train.
So
that
means
they
don't
want
to
put
the
mark
on
the
train,
wait
for
the
merge
request
for
the
pipeline
to
succeed
and
then
eventually
auto
merge
it.
You
actually
want
to
emerge
immediately
and
got
it.
D
So
I
think
yeah
we
should
keep
merge
immediately
for,
in
my
opinion,
because
I
putting
on
the
mr
on
the
first
on
the
first
position
is
actually
different
emerging
immediately,
and
so
I'm
not
sure
would
that
be
the
same
expectations
that
the
user
would
have.
B
C
I
don't
think
it
would
currently,
but
I
guess
that's
why,
if
you
rebase
it's
potent,
then
potentially
the
the
merge
could
still
fail
due
to
it
needing
to
be
rebased
again,
but
yeah
shinyo
is
saying
it's
kind
of
an
edge
case.
So
it's
probably
okay
to
just
have
an
error
happen
in
that
case
and
they
can
try
again.
C
C
Yeah,
that's
what
I'm
imagining
would
happen,
but
I
guess
another
thing
I'm
thinking
about
is:
if
we're
gonna
have
a
merge
immediately
button,
that's
for
hot
fixes!
I
wonder
if
some
customers
might
want
that
to
be
a
to
bypass,
even
the
fast
forward,
merge
just
because,
if
they're,
if
they're,
really
trying
to
like
get
out
a
hot
fix,
quick,
maybe
it's
okay
to
have
the
additional
commit
in
their
history.
C
D
That
means
we
might
need
to
somehow
inject
a
strategy
that
will
override
whatever
is
at
the
project
level,
because
if
you
say
the
project
level,
all
the
mr
must
be
merged
with
fast
forward
marriage.
Then
it
means
that
by
merging
immediately
I
could
potentially
override
that
policy
project
level
policy
and
I'm
not
sure
whether
we
have
like
use
cases
like
this.
That
will
actually
happen.
C
D
But
the
fact
that
that
we
are
saying
that
for
fast
forward
merge,
the
actual
merge
procedure
would
be
always
be
rebase
and
merge.
That
is
consistent,
whether
we
do
it
with
merge
immediately,
although
or
whether
we,
the
mr,
is
merged
as
a
consequence
of
the
merged
train
pipeline
succeeding,
it
will
always
be
the
same.
A
A
I
don't
have
any
more
very
specific
questions,
but
I
mean
if
you
can
see
some
very
obvious
problems.
I
see
very
many
problems
with
the
flow
which
is
in
front
of
us
right
now.
I
mean
that
needs
to
be
fixed
after
this
conversation,
but
if
you
want
to
point
something
out
specifically,
that
should
be
relooked
at
it
would
be
great.
D
I
think
the
main
difference
that
I
can
see
like
between
the
current
strategy
of
marriage,
trade
and
fast
forward
marriage
would
be
with
whatever
we
decide
to
do
with
the
merge
and
what
did
with
the
actual
marriage,
like,
I
think,
the
rest
of
the
of
the
logic
of
marriage
training.
It
shouldn't
really
change
much
like
the
fact
that
how
we
build
the
cascading
refs
how
we
validate
each
pipeline,
those
should
not
change
at
all.
D
What
strategy
we
need
to
use
today
is
we
merge
the
we
use
the
internal
ref
to
create
a
merge,
commit
and
merge
to
master,
but
we
have
to
decide
whether
we
want
to
use
the
internal
ref
to
replace
and
fast
forward,
merge
that
one
or
to
rebase
the
mass,
the
the
branch
and
and
and
merge.
We
have
to
decide
this,
but
I
think
this
in
general
will
be
I'm
not
seeing
other
changes
that
we
have
to
make
to
the
vegetation
logic
like
alizant.
Would
you
agree
with
that?.
C
I'm
not
100
sure,
because
if
it's
set
to
no
fast
forward
when
I
was
doing
the
simulations,
I
you
can't
do
a.
I
mean
sorry
when
it's
such
a
fast
forward.
Only
you
you
can
do
a
fast
forward.
Only
merge
like
if
you
have
branch,
a
b
and
c
you
can't
do
a
fast
forward,
only
merge
of
branch
like
a
into
branch
b.
C
So
I
was
using
a
rebase
like
so
for
branch
c.
I
would
use
a
rebrand
a
rebase
of
a
and
b
into
c,
because
fast
forward
only
wasn't
won't
work
and
then
and
then
I
think.
C
I
I'm
not
sure
if
merge
trains
currently
or
you
are
doing
that
same
thing,
rebasing
or
if
they're,
merging
and
creating
a
merge,
commit
right
now.
D
C
D
Because
they
can
be
so,
let's
say,
safely
merged
with
the
previous
ref,
but
with
fast
for
merge
before
we
merge,
we
might
need
to
because
we
always
merge
against
master.
We
don't
merge
like
a
previous
ref
b
into
ref
a
but
we'll
wait
for
fb
to
be
merged
into
master
right,
so
we
always
merge
the
the
top
of
the
train,
and
so
that
means
we
will
always
have
to
rebase
against
master.
Whatever
top
of
the
train
is
I'm
not
sure
if
I'm
making
sense.
C
C
D
C
Yeah
well
yeah.
Basically,
I
think
the
way
it
works
now
is
you've
got.
It,
creates
the
separate
ref
right
and
then
I'm
not
sure
yeah
if
it
uses
if
it
uses
a
merge
or
a
rebase,
to
get
the
to
get
a
and
b
into
c.
C
But
yeah.
Basically,
are
you
saying
that
it?
It
uses
a
merge
or
do
you
know
if
it
uses
a
mercury
base.
D
I
don't
think
we
use
rebase,
I
think
we
use
merge
because
okay,
we
take
whatever
it
is
in
the
internal
graph
and
we
merge
into
the
previous
ref
which
that
be
becomes
master
in
that
point.
So
the
the
diff
is
the
same,
and
but
we
at
that
point
doesn't
matter
whether
we
use
the
internal
ref
or
we
use
the
branch
we
using.
The
rest
is
safer
because
we
have
already
tested
that
that
we
can
merge
it
and
but
being
because
we
merge
into
master
with
a
commit
yeah.
C
D
It
doesn't
matter
whether
that
commit
is
coming
from
the
from
the
feature
branch
and
it's
coming
from
a
demograph.
The
content
is
the
same
so,
and
that
is
fine,
of
course
today,
with
current
merge
training.
But
if
we
do
fast
forward
merge,
then
we
either
we
rebase
the
the
internal
ref
and
merge
that
or
we
rebase
the
the
feature,
branch
and
merge
that,
but
we
have
the
base
in
order
to
be
able
to
fast
forward
merge.
D
C
I
mean
we
could
technically,
I
guess
in
the
issue:
there
were
some
people
that
want
wanted
it
so
that
you
can
do
a
regular,
merge,
commit
on
your
branch
and
then
like
a
no
fast
forward,
merge
commit
on
your
branch
and
then
and
then
merge
that
via
fast
forward,
but
I'm
not
sure
why
they
want
to
do
it
that
way
but
yeah.
C
I
guess
I
guess
the
thing
is
we
can't
do
a
fast
forward,
merge
right
onto
the
temporary
ref,
but
we
could
do
a
no
fast
forward
merge
or
we
could
do
a
rebase
and
then
integrate
it
back.
C
D
Yeah,
it's
also,
you
know,
I
think
it's
it's
possible
to
do.
Rather
do
the
rebase
merge
the
target
or
the
previous
ref
into
the
current
ref
and
then
do
the
fast-forward
merge
there
and
I
think
it's
possible,
but
we
still
have
to
so
basically
changes
whatever
we
decide.
C
A
D
I'm
assuming
yes,
but
I'm
not
sure,
but
I'll,
listen,
you've
done
anything
other
kind
of
deeper
analysis.
I
haven't
gone
like
100
deep
on
this
part
of
the
code
base.
I
just
try
to
understand
how
everything
works
and
have
noticed
parts
that
need
to
change
and
so
far,
except
for
when
we
say
merge
this
now,
and
that
marriage
strategy
needs
to
be
fast
forward,
because
the
today
will
not
be
applied.
A
Got
it
one
question
fabio
and
alison
you've
been
referring
internal
ref
and
temporary
ref?
Are
they
the
same
thing.
D
Yeah,
I
think
we
call
them
internal,
basically
yeah.
It
will
be
the
merge
tray
in
ref
that
we
used
to
internally
to
merge
the
the
feature
branch
with
the
previous
ref
and
rerun
the
pipeline
there.
So
it
would
be
the
same
terminology.
C
Yeah,
you
can
almost
think
of
it
as
like,
a
a
branch
that,
like
users,
kind
of
can't
see,
I
guess
that's
like
a
way
of
thinking
about
it
and
then
basically
that
branch
just
gets
kind
of
put
on
to
master
okay.
B
All
right,
hey.
A
B
B
That's
right,
it's
behaving
as
if
so
the
ref
is
really
combining
the
new
code
with
what's
already
on
master
and
then
writing
the
pipeline.
D
Of
that
or
or
what
is
in
the
previous
position
of
the
trade
of
the
train,.
B
Oh
I'm
sorry
I
was
saying
outside
of
the
merge
train
feature.
Do
we
ever
do
have
use
for
internal
wraps
and
you
were
saying
in
the
merge
results?
Yes
scenario:
independent
of
it
yeah.
Okay,
all
right.
B
B
Okay,
so
I
can't
tell
from
this
flow
what
would
happen
so
I'll
ask
my
question:
maybe
you
can
point
me
to
the
right
place
in
the
flow.
The
I.
The
thing
that's
confusing
for
me
is
on
a
fast
forward.
Merge
if
it
is
this
new
code
gets
into
master
merged
into
master,
but
all
of
the
all
of
the
refs
in
an
existing
merge
train
was
going
off
of
code
and
master
before
that
fast
forward,
merge
what
happens
to
all
of
those
existing
and
cascading
wraps.
Wouldn't
they
need
to
be
re?
B
B
Mayonnaise
so
mayonnaise
gets
into
master
well,
all
of
the
other
things
that
are
already
on
merge
trains
which
is
like
you
know.
The
first
in
line
is
hamburger.
The
second
one
is
chicken
sandwich
all
of
them.
None
of
them
have
mayonnaise.
B
C
Yeah
you're
saying,
if,
if
something
lands
in
master,
everything
needs
to
be
updated,
yeah
yeah,
I
think,
didn't
chenia
answer
this
for
us
a
couple
days
or
yesterday.
I
think
I
might
have
missed.
B
C
Through
my
slack,
was
it
on
slacker.
B
B
C
Command
line
interface
and
I
believe
shinya
commented
that,
if
matt,
if
someone
pushes
to
master
the
whole
train,
has
to
be
refreshed,
that's
why
I
thought.
B
Okay,
I
I
miss
that
discussion
in
slack.
If
anyone
finds
it,
can
you
just
link
to
that
thread
in
our
agenda?
B
B
B
A
I
have
a
quick
question
about
internal
drip.
I
mean
this
is
just
for
my
own
understanding.
So
in
this
am
I
sharing
something.
A
So
I
was
trying
to
understand
how
pipeline
for
merge
results,
work
and
what
I'm
calling
as
a
pretend
commit
like
when
we
run
pipeline
for
merge
results.
What
it
does
is
it
does
a
pretend
merge
on
to
validate
the
merge
request.
Unexpected
merge
comment
and
then
creates
this
written
comment.
D
So
yeah
we
we,
we
kind
of
simulate
the
merge,
but
we
write
into
a
different
graph,
and
this
ref
is
called
for
example.
Pipeline
for
merge
result
will
be
called
merge,
request,
slash,
merge,
request
id
slash,
I
think
called
merge,
something
like
that
and
we
just
save
it
there
and
we
use
that
to
run.
That
is
like
a
simulation
of
merging
that
into
master
okay,
so
we
already
have
what
that
would
look
like
that
commit
merge
into
master
and
that's
why
yeah
we
we
use
the
same
mechanism
for
magic
trains
as
well.
B
And
I
hope
we're
not
holding
anyone
up.
We
did
go
over
time,
so
I
think
our
next
step
is
we
get
some
user
feedback
if
they're,
okay,
with
what
the
merge
history,
would
look
like
compared
to
an
ex
what
a
merge
space
it
looks
like
now
for
a
fast
forward,
merge
versus
what
it
would
look
like
if
we
supported
fast
forward,
merge
in
merge
train
right,
meaning
we
wouldn't
have
what
they
normally
would
get
in
a
regular
merge
history
for
fast
forward
merge.
B
B
C
Yeah
I'm
gonna
use.
I
can
just
use
the
there's
like
a
get
graph
thing
on
the
command
line
and
I
can
send
it
over
to
you
and
maybe
you
can
make
it
prettier
or
something
all
right.
Okay,.
B
B
Okay,
all
right!
That
sounds
good.
I
wonder
if,
when
you
send
that
over
allison,
if
we
should
add
it
to
a
separate
issue,
vitica
just
for
researching
just
for
validating
this,
just
keep
it
separate
from
the
any
other
issue
on
this.
Okay.
B
Yeah
my
target
is
delivered.
This
really
complex
feature
in
q1,
some
point
so
q1
of
20
fiscal
year
22
is
february
march
and
april.
So
I
know
that
seems
a
ways
away,
but
this
is
so
complex
that
I'm
glad
we're
starting
this
now
because
it's
going
to
take
a
couple
milestones
or
more
to
iterate
through
something.
A
That's
true
yeah,
and
just
to
I
I
wanted
to
mention
that
I'll
be
on
a
10
days,
leave
starting
next
week,
thursday.
So
I
mean
before
that.
My
target
would
be
to
at
least
finish
off
the
preparations
for
the
user
testing,
so
that
when
the
time
by
the
time
we
are
all
back
in
office,
I
mean
virtual
office
yeah.
We
could
easily
get
up
to
our
users.
B
Yeah
and
I-
and
I
I
think
that
might
be
beginning
of
the
year-
it'd
be
the
first
time
to
to
send
it
to
our
user
because
they
probably
won't
give
it
the
attention
it
needs
the
last
I
don't
know
right
to,
and
I
want
to
be
available
to
answer
their
questions
too,
and
I
know
a
lot
of
us
are
out
the
last
couple
weeks
of
the
year.
B
Okay,
thanks
folks
for
joining.
Let
me
stop
the
recording
I'll
I'll
link
to
the
recording
from
our
agenda
or
to
our
agenda.