►
Description
Presented by Pablo Santos Luaces, Chief Engineering Officer and Founder, Códice Software
About GitMerge
Git Merge is the pre-eminent Git-focused conference: a full-day offering technical content and user case studies, plus a day of workshops for Git users of all levels. Git Merge is dedicated to amplifying new voices in the Git community and to showcasing the most thought-provoking projects from contributors, maintainers and community managers around the world. Find out more at git-merge.com
A
What
I'm
going
to
say
is
that
I'm
going
to
try
to
tell
the
story
of
an
obsession
right,
an
obsession
that
the
entire
team
and
I
have
about
trying
to
create
better
merging
and
dipping
right
so
before
we
start
before,
I
start
I'm
going
to
share
a
little
bit
of
who
we
are
right.
As
we
said
before,
we've
been
for
will
being
in
business
for
13
years
already
doing
version
control.
We
are
a
small
team
of
17
people.
A
We
are
located
here
based
here
in
Spain,
although
we
have
customers
all
around
the
world,
our
main
thing
is
plastic.
Sem
we
develop
a
version.
Control.
It's
not
based
on
get
is
a
completely
different
stack,
but
we
also
develop
gooeys,
server-side
and
then
tons
of
merge
tools.
Well
different,
merge
tools,
which
is
the
thing
of
a
focusing
on
today,
and
then
we
have
developed
something
we
call
semantic,
define
and
merging,
and
we
put
all
together
into
a
git
client,
which
is
what
what
walls,
which
is,
what
drives
the
entire
list.
A
The
entire
story
happy
sharing
nap.
So
what
is
this
session
all
about?
This
is
the
agenda.
I
have
I'll
first
start
by
well.
Making
a
question
is
text
if
I
merge.
The
end
of
the
trip
is
the
end
of
story.
As
I
said,
we
have
an
obsession
with
that
I
mean
we
really
want
to
come
up
with
something
different.
This
is
what
we've
been
working
on
for
the
last
few
years,
so
we
think
is
not
the
end
right,
so
we
think
there's
there's
more
than
that.
A
Well,
after
that,
I'll
be
hearing
a
few
numbers
of
some
experiments
we
ran,
so
we
give
you
a
little
bit
of
context.
Then
I'll
be
walking
through
the
different
steps
we
went
through
over
the
last
years,
like
the
first
initial
approach,
then
really
go
in
semantics
and
then
go
in
multi
file,
so
I
hope
it's
as
interesting
for
us.
I
think
it
is
so.
First
of
all
is
what
we
mean
by
semantics
right
to
give
you
a
little
bit
of
context.
Okay,
look
at
this
sample.
A
This
is
the
base
of
a
merge
how
a
file
was,
and
we
have
a
method
there.
This
is
coming
from
leaf,
get
too
sharp
and
okay.
We
have
a
remove
method
there,
and
then
someone
makes
some
modification
to
these
methods
and
move
this
up
in
the
file
because
he
thinks
it's
a
better
idea
to
have
it
sorted
on
a
different
way
and
then,
in
parallel,
someone
else
modifies
the
method
to
and
moves
it
down.
What
happens
when
you
try
to
merge
this
with
a
traditional
three-way,
merge
tool?
A
Okay,
normally,
except
if
I
did
something
wrong,
you
wouldn't
have
any
conflicts,
and
you
end
up
with
three
copies
of
your
methods.
Probably
it
won't
compile
well
one
compile
and
well
it
will
go
okay,
it
was
merged,
probably
even
automatically,
and
you
end
up
with
something
doesn't
even
build.
Well,
this
is
what
we
can
see
there
semantic
issue.
Probably
syntactic
would
be
better,
but
semantic
is
like
a
bigger
word,
so
we
like
it
better.
A
So
that's
it
so
a
few
numbers:
okay,
how
it
goes
so
we've
been
running
a
few
thousands
experiments
on
what
we
call
merge
replay,
which
is
okay.
We
download,
like
a
few
I,
said
more
than
1000
to
think
we
went
beyond
that.
A
thousand
get
half
public
repositories,
we
download
them.
We
walk
the
DAC
and
I
think
we
do
walk
the
dog
backwards
so
that
so
and
what
we
do
is
reply.
The
merge
like.
A
Okay,
we
get
the
destination
of
the
merge,
we
go
back
and
then
we
reply
the
merge
and
try
to
reproduce
it
right,
and
what
we
found
out
is
that
about
when
we,
when
you
merge
branches
like
50%,
less
of
manual
conflicts
are
needed,
which
means
we
are
trying
to
really
avoid
manual
intervention,
which
is
what
really
scares
you
off
right.
So
full
branch
merge
means
all
the
files
in
the
merge
can
be
automatically
merged
or
they
are.
A
They
are
in
conflict
15%
less
times
than
don't
done
with
the
regular
merge
right
and
if
you
go
for
individual-
and
we
think
this
is
very
interesting
because
it
means
lots
of
pull.
Requests
that
are
now
in
I
mean
that
now
the
need
manual
intervention
could
be
fully
automated.
That's
a
that's
a
good
number
right
and
then
the
receiving
a
bigger
number,
which
means
that,
even
if
your
branch
cannot
be
fully
merged,
still
many
of
the
other
files
inside
in
conflict
can
be
automatically
merged
by
this
approach,
and
we
found
out
less
like
thirty.
A
Two
percent,
less
of
in
average,
of
merges
of
individual
files
need
manual
intervention
following
this
approach.
Ok,
this
and
well
is
the
end
unit
repository
and,
of
course,
what
I
share
is
the
average,
but
the
average
was
sometimes
not
as
good
as
respected,
so
we
shared
this
number,
which
is
much
better
and
ok
just
to
give
you
an
idea,
I
mean
in
some
repose
it
can
get
even
better,
as
you
can
see,
here
is
almost
37
percent
of
branches
being
completely
well.
A
37
percent,
less
of
manual
intervention
on
branches.
Okay,
we
created
a
small
analyzer
that
you
can
check
later.
It's
a
really
simple
thing:
you
just
submit
your
github
repo
and
it
tells
you
how
much
time
or
how
many
merges
you
can
actually
automate
by
using
this
sort
of
approach
to
merge
it.
Okay,
if
you
have
lots
of
CML
files
and
not
really
the
source
code,
we
support,
then
you
will
get
better
results,
but
that's
the
idea.
A
Okay,
so
the
and
then
our
remark
right
I
mean,
unlike
a
starting
from
the
results
and
now
I'm
going
to
show
you
the
the
entire,
the
entire,
the
entire
train
of
thought.
We
follow
one
one
remark:
all
these
happens
even
when
we
all
try
to
avoid
doing
reef
actors,
while
someone
else
is
touching
the
same
code
right
and
it
still
happens
so
or
view
or
vision-
is
that
Sunday.
If
we
all
take
take
advantage
of
this
approach
to
define
emerging
there,
it
will
happen
more
and
we'll
we
automate
it
more,
also,
okay.
A
So
this
is
how
we
started
finding
moved
code
through
fragment
similarity.
We
call
it
cross
different
cross
merge,
because
we
now
we
like
cool,
as
I
said
before
and
okay,
what
we
do
is
we
calculate
the
diffs,
how
it
works
right,
what
we
did
and
we
started.
We
had
this
for
years
already
we
started
long
ago.
What
we
do
is
that
the
techniques
go.
The
technique
goes
as
follows:
we
calculate
the
diff
and
then
we
try
to
match
added
and
deleted
blocks.
A
So
whatever
is
added
and
the
lead
is,
is
a
potential
candidate
for
a
move,
and
this
is
how
we
track
moved
code
within
a
file.
The
nice
approach
and
and
and
the
similarity
algorithm
we
use,
is
something
very,
very
similar
to
what
git
uses
internally
to
actually
track
move,
move
files
and
so
on.
So
it's
almost
the
same
approach
and
well
then
we
have
a
challenge
in
GUI
space,
which
I
show
one
of
the
solutions,
because
you
have
to
represent
that.
So
the
user
really
understand
it
right
so
for
merge.
A
It
does
something
a
little
bit
more
tricky,
which
is
it
calculates
the
candidates
like
okay,
if
you
move
some
code
to
a
different
place
in
the
same
file
within
the
same
file,
what
happened
if
something
else
also
modified
in
the
original
or
Chandeleur
that
I'll
show
you
it
with
an
example.
Well,
the
benefit
of
this
approach,
which
was
or
an
original
approach
to
the
problem
is
that
is
called
agnostic.
It
works
for
c-sharp.
You
will
see
it
works
for
for
love
letters,
it
works
for
whatever
right
it
doesn't
care
about
the
actual
language.
A
Underneath
this
is
a
screenshot.
A
very
old
one
of
cross
leaf,
like
you
see,
is
a
fragment
of
code
being
moved
and
well.
We
paint
somehow
a
line
saying
it's
the
same
thing.
The
detection
is
the
important
thing
that
I
want
to
share
in
this
session,
and
it's
like
well
what
explained
before
right
like
matching.
What
was
you
see?
There's
a
mole,
a
block
being
a
block
me
being
deleted,
there's
another
one
being
added,
and
then
it's
much
because
it's
quite
similar,
then
for
merge
is
a
slightly
more
complicated.
A
It's
still
a
very
manual
process,
but
it
can
help
in
certain
cases,
not
in
all
cases,
but
in
certain
cases
this
is
a
typical
example.
What
you
have
on
the
center
is
the
base.
The
ancestor
hide
was
then
one
contributor
and
the
other,
and
this
is
a
typical
case
for
what
we
call
the
cross
merge
and
is,
and
what
happens
is
okay.
You
have
some
code
that
was
modified
and
then
on
the
other
contribute
was
deleted,
chances
are,
or
we
think
this
is
a
good
heuristic
chances
are.
A
The
code
has
been
moved,
so
we
show
an
action
on
the
on
the
screen.
Saying:
ok,
you
can
cross
merge
this
and
when
you
click
on
this
it
will
say:
okay,
you
know
what
I
find
a
similar
fragment
of
code
in
a
different
place,
so
you
can
go
and
pick
up.
The
three
fragments
merge
it
with.
This
is
what
we
call
submerge,
because
you
pick
up
the
fragments,
merge
them
with
a
three-way,
merge
tool
and
then
put
the
result
on
the
destination.
A
This
was
our
first
approach
right
and
we
use
it
for
four
years
is
not
magic.
I
mean
it
doesn't
work
in
all
cases,
but
we
thought
it
was
great
at
the
beginning,
then
we
went
for
what
we
said.
It
was
the
semantic
approach.
As
I
said,
it
will
be
more
like
a
syntax
based
thing
and
here's
how
it
works.
We
start
with
a
file
and
then
we
parse
it
and
we
create
a
tree.
It's
not
like
an
AST
because
it's
a
little
bit
simplified.
A
Basically,
all
we
care
about
is
are
the
positions
of
the
declarations
on
within
the
file.
As
you
can
see
here
we
have
an
add
method
and
then
we
all
care
all.
What
we
care
about
is
the
position
where
it
is
where
it
ends
and
and
so
on
right.
So
we
parse
the
code,
we
create
a
tree
and
we
will
work
based
on
that.
A
Actually,
the
format
is
a
little
bit
more
complicated,
and
here
is
one
of
the
places
where
there's
a
lot
of
room
for
improvement
for
us,
because,
instead
of
storing
like
only
the
where
it
begins
and
in
end
it
ends
based
on
row
and
column,
we
just
we
make
the
guy
doing.
The
parser
actually
count
the
characters,
which
is
a
little
bit
painful,
but
it
works.
A
What
we
do
is
try
to
match
the
notes
right,
like
okay,
I,
the
two
versions
of
the
file
and
then
I
start
with
verse
method
called
at
and
I
try
to
find
it
in
the
other
version
in
the
other
tree.
If
it's
there,
it's
a
match.
Nothing
happened
if
it,
if
it's,
if
you
don't
find
it,
you
mark
it
as
at
least
temporarily
removed
and
then
the
same
happens
with
added
methods
and
so
on.
In
order
to
much,
we
follow
a
very
simple
approach,
which
is:
okay,
same
method,
names,
a
method
name.
A
If
the
bodies
are
the
same
thing,
then,
is
the
same
method.
If
the
bodies
are
not
exactly
the
same,
then
we
again
reuse
the
previous
code.
We
did
for
the
X
diff
the
cross
DIF,
which
is
okay.
How
similar
they
are
so
just
just
just
to
make
it
clear
what
we
do
is
that
we
stop
at
the
declaration
at
the
method,
level
or
the
function
or
the
declaration
I
mean
we
don't
parse
the
eaves
and
else
and
force,
and
all
that
I
mean
we
treat
the
bodies
as
text.
So
we
get
the
structure.
A
Everything
is
everything
else
as
text.
So
what's
the
nice
thing
with
this
way
of
dipping
okay,
you
move
a
method
to
different
location.
We
still
know
is
a
saddle
same
method,
because
it's
very
similar
and
so
on.
We
can
also
track
renames
like
either.
Bodies
are
the
same
and
the
method
names
change.
Well
it
it
was
modified
right.
So
that's
how
it
works
right.
That's
the
second
approach.
We
we
had
right.
So
what
happens
to
to
merge?
Well,
we
reuse
the
difficult
well.
A
A
Here
we
reuse
a
lot
of
the
work
we
previously
did
for
files
and
directories
with
version
control,
implementation
right.
So
a
lot
of
the
work
we've
done
there,
or
at
least
the
the
knowledge
we
got
from
there
we
applied
here.
So
we
start
calculating
different
types
of
conflicts,
and
some
of
them
are
explaining
a
few
of
those
right.
A
But
some
of
them
are
things
like
cyclic
move,
divergent
move
like
what
happens
if
you
move
the
same
key
to
two
different
places
in
parallel,
like
the
one
you
saw
before,
evil
twins,
which
is
again
a
pretty
cool
name
and
then
specific
constructs
like,
for
instance,
suppose
you
have
well,
we
develop
mostly
in
c-sharp
and
although
I
love
three
but
anyway,
so
suppose
you
are
the
using
and
someone
else
from
the
team
at
exactly
the
same,
using
three
lines
below
that.
Well,
it's
very
very
simple
to
know
this
is
a
using.
A
So
it's
not
even
a
conflict.
You
just
keep
one
of
them
automatically
solved
right.
It's
not
a
big
deal
to
solve
it
manually
either,
but
you
know
it
can
do
it
this
way.
So
a
few
of
the
conflicts
here
well-
and
this
is
what
names
actually
my
session,
because
this
is
my
favorite
Merc
merge
case.
Look
at
the
look
at
the
look
at
the
a
scenario
you
have
a
class
which
is
like
a
socket
implementation
will
listen
and
connect
and
so
on,
and
then
you
decide
to
refactor
in
two
different
ways.
A
You
want
to
create
some
source
and
sync
all
trying
socket
and
then
another
thing
called
server
socket.
This
is
the
base.
This
is
what
one
contributor
did.
This
is
what
the
other
contributor
did
right
with
the
semantic
approach.
This
is
a
automatic
merge,
no
conflict.
Why
look
at
the
annotations?
No,
no!
The
method
has
icons
well,
I
use
icons,
who
can
be
whatever
anything
else
right
on
the
two
sides,
so
there
are
no
conflicts
are
all.
A
If
you
try
this
with
a
regular
text
based
approach,
what
you
will
get
is
some
is
the
code
trying
to
match
get
host
by
name
which
was
modified
in
one
contributor,
trying
to
match
it
with
the
Declaration
of
the
server
socket?
So
you
know
sorry,
with
with
reg,
be
most
likely
so
you'll
be
hitting
something
that
doesn't
make
a
lot
of
sense.
I
mean
you'll,
have
tons
of
conflicts
in
any
scenario
like
this,
and
it
will
be
a
little
bit
complicated
to
solve.
A
With
the
semantic
approaches
automatic
you
will
get
the
classes,
I
mean
you
will
even
get
the
rename
of
the
old
socket
question
to
DNS
and
so
on
completely
automatic.
Ok,
the
other
day
between
also
very
common
someone
else.
Someone
have
a
class
there's,
nothing,
no
modifications
or
anything
but
sorry,
a
class,
a
method
and
someone
else
at
another
method
on
a
different
location
again
using
the
semantic
approach
instead
of
duplicating
and
then
detecting
it.
A
During
a
deal
time,
the
merge
is
smart
enough
to
actually
figure
out
it's
the
same
thing,
so
it
keeps
just
one
of
them
which
one
I
think
of
the
current
heuristic
we
use
is
like
I,
don't
know
the
first
one
it
finds
by
position
or
something
it
won't
affect
the
build.
So
it's
okay,
okay
and
then
my
second
favorite,
which
is
divergent
move.
Okay,
I
started
where
I
finished.
A
With
my
previous
socket
example,
then
I
have
the
listen
method
and
then
what
happens
if
I
move
it
to
client
socket
again,
it
doesn't
make
a
sense
or
all
to
move
it
there
probably,
but
you
know
it's
just
for
the
sake
of
the
examples
of
one
developer,
one
contributor
move
it
to
one
location.
While
someone
else
move
it
to
a
different
location,
it's
still
happening
within
the
same
file.
Well,
what
you
will
get
here
is,
instead
of
you,
know,
a
lot
of
conflicts,
the
the
tool
saying
well,
the
tool
can
detect.
A
That
is
the
same
method
that
was
modified
in
two
places
and
that
you
have
to
choose
whether
you
want
it
to
a
location
or
the
other.
So
what
you
will
expect
here
when
you
solve
this
is
like
okay.
Where
do
you
want
to
put
it
and
as
soon
as
you
decide
on
the
structure
conflict,
it
will
say:
okay
now
I
merge
the
the
content
and
then
it's
a
simple
three-way,
merge.
Ok,
so
the
thing
here
is
that
everything
I
explained
so
far
happens
within
a
single
file
right,
but
the
real
stuff.
A
The
the
real
thing
we
wanted
to
do
from
the
very
beginning
was
to
really
implement
this
cross
file,
and
this
is
where
some
of
the
challenges
started
and
well
that's
what
I'm
going
to
share
from
for
now
on.
Okay,
so
multi
file,
as
I
said,
was
the
goal
from
the
very
beginning,
but
for
for
all
the
previous
steps,
we
could
rely
on
being
invoked
as
a
regular
three-way,
merge
tool
like
you
configure
your
git
and
instead
of
calling
I,
don't
know,
KD,
3
or
whatever
you
just
invoke
or
tool.
A
You
get
the
three
contributors
and
you
are
done,
but
in
order
to
do
real
different
merge
for
multi
file,
you
need
a
different
approach,
because
you
need
more
information
and
that's
what
I,
what
I
am
going
to
explain?
Basically
well,
we
call
the
diff
that
the
cross
filed
if
we
call
it
refactor
detection,
that's
something
we
also
like.
A
We
need
a
deeper
interaction
with
version
control,
so
it's
not
version
control
agnostic
anymore,
and
this
was
one
of
the
reasons
that
trigger
has
to
start
last
year,
developing
a
new
git
client
right,
which
is
this
G
master,
that
we've
been
working
on
for
the
last
few
months?
Okay,
so
this
is
a
cross
file
what
it
does
well.
These
are
an
example
of
the
following
from
the
for
the
next
minute.
A
A
In
fact,
this
graphic
here
is
actually
is
actually
taken
from
that
from
the
tool
itself
right,
so
how
we
calculate
it,
because
that's
the
part
of
the
story
I
want
to
focus
on
well,
we
calculated
on
the
on
the
following
way:
basically,
we
parse
each
of
the
files
on
the
commit.
You
are
dipping
right.
That's
the
first
thing
we
do
so
we
parse
each
file.
A
A
Declarations
we
try
to
match
them
across
files.
Everything
before
happened
on
a
single
file.
Now
we
get
the
list,
we
try
to
match
them
following
exactly
the
same
heuristics.
We
did
before
like
okay,
much
the
content
content
similarity.
We
do
some
tweaks
here
and
there
with
the
part
arguments
of
the
methods
and
things
like
that
right
and
well,
of
course,
for
as
the
devil
is
in
the
details,
I
mean
it
must
be
fast
enough.
I
mean
the
overall
explanation
is
likely
what
I?
A
What
I
told
you,
but
then
there
are,
as
you
might
imagine,
a
few
details
here
and
there
so
later
on.
Once
you
have
that
we
can
call
something
we
call
the
soup
thief,
so
you
can
click
and
actually
diff
the
same
method
even
across
the
different
files,
and
you
just
get
the
two
fragments
and
call
a
standard
if
write
text
based
if
pretty
simple,
so
that's
the
what
we
call
the
refactor
detection.
Okay.
A
A
Well,
here
is
a
branch
diagram,
and
this
is
actually
what
happened
here
is
the
commit
where
I
detected
this
refactor
moving
a
method
to
a
different
file.
Actually
I
move
it
from
period
CS
to
time
period,
field
OCS,
but
then
here
someone
else
from
the
team
in
parallel
decide
to
actually
modify
the
original
methods
on
its
original
location.
Okay.
A
So
when
you
want
to
merge
this,
as
I
said,
you
need
more
info
for
the
version
control.
Why?
Because,
when
you
merge
that
okay,
you
asked
merge,
you
asked
it
to
merge
this,
and
then
it
will
probably
detect
a
conflict
on
period
CS
because
it
was,
it
was
modified
by
the
two
contributors,
but
the
other
file
time
period
field
is
not
in
the
index
because
not
in
conflict.
It
was
modified
before
and
his
word
up.
Well
what
the
real
thing
comes.
A
This
were
we
we
need
deeper
inter
integration
and
that's
why
being
an
independent
wasn't
enough
for
an
initial
approach.
If
we
run
this
from
our
own
client,
what
we
do
is
not
only
use
it
as
merge
tool
we
drive
into
our
merge.
We
asked
the
league
get
to
to
actually
do
part
of
the
merge
and
then
we
say
hey.
We
have
all
these
differences
on
the
index
normally
well,
they
are
they're
actually
and
then
we
need
to
diff
destination
and
base.
We
do
that
to
actually
get
the
other
files
involved
in
the
merge.
A
They
cannot
be
in
conflict
or
maybe
they
are
not
in
conflict
like
in
this
case,
but
there
can
be
involved.
Then,
once
we
have
this
list,
we'll
get
the
two
files
we
need
period,
CS
that
was
on
the
index
and
time
period
field
which
wasn't
then
we
parse
them,
and
then
we
calculate
the
diffs
for
each
of
the
contributors
like
before,
like
with
the
base
and
so
on,
and
then
we
get
the
entire
trees
of
all
the
contributors
and
we
start
doing
the
all
the
divs.
A
A
Well,
that's
just
exactly
what
I
explained
that
we
need
to
give
the
destination
versus
the
base
and
time
period
field
is
not
in
country,
but
it's
involved
so
how
multi
file
is
calculated.
As
I
said,
we
parse
all
the
involved
file
by
involved.
We
mean
what
I
just
plain
like
everything
in
there.
Then
we
calculate
a
merge
based
on
that
and
it
is
again
like
an
individual
file.
Merge
like
an
individual
semantic.
Merge.
You
go
just
trying
to
calculate
on
the
conflict.
All
the
countries
are
so
on,
but
then
all
the
other
than
deleted.
A
That's
a
magical
with
all
the
other
done
deleted,
our
move,
candidates
even
cross
file,
and
that's
what
we
calculate
how
it
looks
like
it
looks
like
this.
This
is
an
actual
graph.
It
you
can
get,
which
is
I
mean
when
you
have
like
sample
classes
with
three
methods.
It's
very
nice
to
see
when
you
have
hundreds
of
them,
it's
a
little
bit
more
complicated
but
as
we
saw
before,
with
solid
principles
and
so
on,
you
should
have
so
many
methods
anyway.
So
well,
that's
actually
the
conflict
that
we
represent.
This
is
a
very
good.
A
This
is
actually
what
we
show
to
the
user,
but
it's
also
a
representation
of
what's
going
on
behind
the
scenes,
because
what
we
get
is
get
angry
between
was
modified
and
so
on.
What
you
get
here?
Well,
the
next
challenge
for
us
once
we
detect
it
and
that's
something
we
struggle
with
for
really
a
lot
of
a
long
time
was
how
to
show
that
to
the
user.
Without
you
know,
driving
him
crazy
or
something
like
that.
So
once
we
do
that,
basically,
what
we
have
to
do
is:
okay,
first,
let
him
decide.
A
Okay,
you
need
to
merge
this.
You
need
to
solve
the
conflict
and
then
it's
going
to
be
in
to
incorporate
it
here.
That's
the
simple
part,
but
the
good
thing
is
how
to
represent
it.
So,
as
I
said,
we
struggle
with
that,
and
then
we
went
for
different
alternatives,
I'm
going
to
explain
one
of
the
first
one.
This
is
not
even
the
tool
itself
is
like
Visio,
drawing
and
paint.
A
So
what
we
have
at
the
very
beginning,
with
a
special
opera
with
the
first
approach,
was
like
a
very
alien
solution
like
okay,
we
show
all
the
conflicts,
and
then
we
show
diffs
and
so
on,
but
you
really,
except,
if
you
get
this
view,
you
really
didn't
get
what
was
actually
happening
right
and
then
the
first
version
we
release
is
actually
a
few
years
ago
of
the
merge
solution.
Even
before
going
multi
file.
Look
more
like
this
right.
A
But
it's
decorated
because
the
merge
tool
is
having
information
not
only
of
the
three
files
in
both
in
a
regular
merge,
but
all
the
files
involved
in
the
multi
file
right
once
you
get
that
it
can
tell
you
well,
this
method
is
special
because
the
underlying
data
that
it's
telling
you
it's
been
moved
and
so
on.
So
you
go
click
to
merge
it
and
what
you
get
is
the
other
contributors.
I
mean
the
other
contributor.
That
is
on
the
other
file
right.
A
What
was
on
the
other
file,
so
the
end
result
is
that
you
get
the
change
made
in
parallel
by
your
colleague
here
incorporated
in
the
final
in
the
final
version,
do
you
move
to
a
different
place
and
that's
what
the
multi
fathom
antic
is
all
about.
It's
still
not
I
mean
we
can
detect
different
types
of
methods.
It's
still
work-in-progress.
We
have
several
things
to
improve.
Think
there
are
some
divergent
move
cases.
A
A
You
have
to
choose
not
like
the
one
I
show
you
you
have
to
choose
which
one
you
want
and
then
you
merge
it,
but
it's
also
very
helpful
in
a
in
a
very
simple
case,
which
is
when
you
just
move
something
to
a
different
location
in
the
location
there
you
have
to
incorporate
or
regional
changes
like
I
showed
before.
So
what
is
next
for
us?
Well,
there's
something
I
forgot
to
say
even
on
a
single
file
conflict
and
a
single
file
merge.
A
If
you
have
conflict
on
conflicts
on
a
method,
it
can
be
that
the
method
could
be
merge
automatically,
but
you
want
to
review
it
a
typical
example
where
something
is
modified,
the
beginning
of
the
method,
something
is
modified
at
the
at
the
end,
with
a
semantic
approach,
you
can
mark
it
as
a
conflict.
If
you
want
to
ensure
it's
always
revealed
right,
ok,
so
the
ideas
we
have
for
the
future,
some
of
them
we've
been
working
on.
A
Some
of
them
are
just
we
still
thinking
semantic
blame
like
ok,
you
go
blaming,
but
actually
tracking,
all
the
move
code,
even
macros
files,
the
cross
fault,
semantic
blame
as
I
said
here,
that's
something
we
use.
We
never
try,
but
it's
always
like.
Oh
my
own
or
mines
method,
history.
It
is
very
good
for
c-sharp
Gavin.
So
on,
like
you
right-click
on
a
method-
and
you
show
the
history
of
of
this,
you
basically
go
back
parsing
all
the
versions
of
the
file
and
showing
exactly
what
it
was.
A
But
what,
if
you
extract
part
of
it
to
a
different
location,
something
that
is
on
our
roadmap
and
then
support
for
more
languages
like
right
now
we're
doing
our
L
box,
C
sharp
C,
C++
and
Java,
but
we
would
like
to
extend
it
to
two
others
and
then
also
support
different
types
of
files
like
in
the.net
world.
There
are
sometimes
conflicting,
dots,
CS,
prog
and
stuff
like
that,
so
doing
this
kind
of
stuff,
so
that's
basically
or
trip
through
the
semantic
dipping
and
trying
to
do
really
difficult,
Maria's
automatic.
Thank
you.