►
Description
Autodesk is moving hundreds of Perforce repositories to GitHub. Lars Schneider will present the process by which these repositories were moved, what problems we encountered so far and how we solved them.
The talk includes an extensive overview how to migrate source code from Perforce to GitHub. This knowledge will assist anyone in estimating the risk for a Perforce to Git migration, and help to ensure their own migration will be a breeze.
About GitHub Universe:
Great software is more than code. GitHub Universe serves as a showcase for how people work together to solve the hard problems of developing software.
For more information on GitHub Universe, check the website:
http://githubuniverse.com
A
Welcome
everybody:
my
name
is
Lars
Schneider
and
I'm.
The
technical
lead
for
getup
solutions
at
Autodesk.
Right
now
we
are
migrating
hundreds
of
projects
with
millions
of
source
code
lines
from
perforce
to
gate,
and
in
this
talk,
I
want
to
share
the
lessons
we
have
learned
so
far,
but
first
of
all,
who
is
Autodesk
out
of
this
is
best
known
for
AutoCAD,
a
2d
and
3d
computer-aided
design
software.
A
We
are
software
in
the
architecture,
engineering
and
construction
space.
We
have
software
in
a
manufacturing
space
and
we
have
software
in
a
media
and
entertainment
space,
and
if
you
have
been
to
the
cinema
in
the
last
ten
years,
you
have
most
certainly
seen
the
results
of
this
software
and
more
recently,
we
are
also.
We
also
have
hardware
in
software
in
the
3d
printing
space,
because
we
think
3d
printing
is
the
future
of
making
things.
A
So
why
would
we
migrate
our
source
code
to
get
well?
First
and
foremost,
we
want
to
stand
as
allies.
As
I
said,
we
are
run
for
30
years
and
we
are
growing
every
year
we
are
trying
new
companies
with
new
products
and
all
these
different
products
right
now
they
use
different
source
control
systems
and
we
use
perforce
get
TFS
SVN
everything
and
the
biggest
ones
are
really
perform
and
get
right
now
and
we
decided
to
go
with
git
and
only
with
get
that
helps
a
lot,
because
we
can.
A
We
can
set
up
our
continuous
integration
more
easily
and
our
code
review
tools.
Everything
is
very
easy
to
set
up
if
we
have
just
one
source
control
system
and
every.
If
we
have
all
source
in
one
system,
then
we
enable,
on
the
end
our
engineers
to
discover
source
code
more
easily.
If
they
can
discover
source
code,
they
can
actually
share
and
reuse
the
source
code,
and
that's
really
what
we
want
them
to
do.
We
don't
want
them
to
reinvent
the
wheel
over
and
over
again.
A
So
what
will
you
learn
today?
First
I
will
show
you
how
you
migrate
repositories
from
perforce
to
get
using
a
tool
called
get
p4.
I
will
show
you
how
you
might
how
to
migrate.
History
I'll
show
you
how
to
handle
file.
Encodings
I
will
show
you
how
to
migrate
branches
and,
most
importantly,
I-
will
show
you
how
to
enter
binary
files,
and
fortunately
most
migrations
are
not
that
easy.
A
Sometimes
you
need
to
restructure
your
repositories
and
I
will
talk
about
this
too,
and
last
but
not
least,
I
will
talk
about
non
technical
issues
that
we
run
into
and
that
you
probably
will
run
into
too,
but
first
I
will
show
you
how
to
use
git
p4
what
is
get
before.
It
is
a
Python
tool
that
comes
with
a
gate,
distribution
and
it
helps
you
to
migrate
source
code
from
purpose
to
get
does
all
the
heavy
lifting
for
you.
So
how
do
you
use
it?
First,
you
need
to
set
up
perforce.
A
A
Then
we
create
a
new
directory
and
CD
into
this
directory,
and
now
it
gets
interesting.
We
invoke
get
p4
with
a
couple
of
parameters.
The
first
one
cloned,
it
tells
could
be
for
two:
take
the
powerful
suppository
and
move
it
to
get.
The
second
one
is
the
base
path
of
the
purpose
repository
that
we
want
to
migrate
and
look
at
the
suffix
at
all.
That's
super
important
here,
because
this
suffix
child
skipped
e4
to
move
all
history
tribute.
That
means
all
change
lists
in
perforce
will
become
get
commits.
A
The
third
parameter
just
tells
get
before
to
store
the
result
in
get
repository
right
in
that
directory
and
the
last
parameter
verbose
gives
us
some
details.
What's
going
on
when
get
p4
is
actually
running,
so
this
command
will
run
quite
a
while,
depending
on
the
size
of
your
repository,
but
eventually
it
will
finish
and
then
your
repository
is
on
your
local
machine.
A
So
what
you
want
to
do,
then,
is
you
add
a
remote
to
push
your
repository
up
to
get
up
like
that
and
that's
it.
It's
easy
as
that,
and
fortunately
not
all
migrations.
Are
that
easy?
Sometimes
you
need
to
move
around
certain
directories
to
make
yet
in
a
to
generate
the
desired
structure
and
you
get
repository.
A
How
can
you
do
that?
Well,
perforce
has
a
pretty
powerful
concept.
It's
called
the
client
spec
and
the
client
spec
is
a
configuration
of
or
the
clients
that
confluent
configures
the
local
view
of
your
traffice
repository.
As
you
can
see
here,
there's
the
section
view
and
then
you
can
shuffle
around
repository
around
directories
and
define
where
you
want
to
have
certain
directories
in
your
get
repository.
A
But
how
do
you
use
a
client's
back
with
git
before?
Well,
that's
not
too
hard
at
first.
You
need
to
note
this
client
spec
integrate
before
into
before.
You
need
to
invoke
this
line
and
you
use
the
p4
client
command
for
that
action.
Then
you
go
along
with
making
extra
direct
mic
in
the
directory
and
see
the
introduced
directory,
and
then
you
do
something
different.
You
initialize
a
git
repository.
Why
do
you
do
that?
A
Well,
get
p4
uses
the
contact
mechanism
of
get
for
all
its
options,
and
here
we
target
before
to
use
a
client
spec.
That's
the
first
thing
you
need
to
do.
The
second
thing
is
you
need
to
target
before
what
client
spec
you
want
to
use
all
clients.
Legs
have
a
name,
and
here
we
call
it
project
X
spec,
and
then
you
run
your
migration
as
I
just
sort.
You
one
slide
before,
and
it
just
works.
A
Not
quite
because,
at
this
point,
I
did
run
in
my
first
into
the
first
pitfall.
Let's
consider
this
very
simple
perforce
repository
as
you
can
see,
there's
one
directory
case
and
it
contains
two
files,
a
file
and
B
file,
so
we
used
it
before
we
use
a
client
spec
andr,
my
great
the
source
code,
and
what
we
end
up
with
is
a
repository
that
contains
only
one
file.
Well,
that's
weird
right!
A
So
I
took
a
closer
look
at
my
purpose
repository.
Can
you
spot
it?
Well,
if
you
look
at
the
path
of
the
individual
files,
you
will
see
that
the
path
is
the
same,
but
it
uses
a
different
case
and
at
this
point
I
remember
well
our
perfo
server.
They
run
in
case-insensitive
mode.
It's
quite
useful
if
you
have
Windows
clients,
ok,
so
I
thought,
I
understood
the
problem
and
I
searched
to
get
help.
A
Files
and
I
found
this
interesting
conflict
core
ignore
case,
so
I
set
it
to
true
and
I
thought
should
solve
the
problem
right.
Unfortunately,
no,
it's
still
just
one
file
in
my
resulting
git
repository,
so
I
decided
to
go
a
little
bit
deeper
and
debug.
Actually
get
p4
and
guess
what
I
found
but,
and
fortunately,
I
was
able
to
fix
that
back
and
oops,
and
now
we
have
and
now,
when
you
and
now
we
can
migrate,
your
repository
and
both
files
will
end
up
in
your
get
repository.
A
A
Okay,
the
next
pitfall,
I
run
into
was
path
and
coding.
If
your
get
repository
looks
like
this
after
the
migration,
then
you
probably
have
non
ASCII
characters
in
your
path
names.
So,
what's
going
on
there?
Well,
it
turns
out
perforce
encodes
path,
names
with
the
encoding
of
the
machine
that
makes
the
submission
omit.
A
That
means,
if
you
use
a
Windows
computer,
a
Western,
European,
Windows
computer,
your
path,
names
are
encoded
with
CP
1252,
encoding
and
gate
expects
utf-8
encoding
for
all
paths
and
that's
the
reason
why
you
end
up
with
these
weird
characters,
so
I
understood
the
problem.
But
what
can
we
do
about
it?
A
Let's
talk
some
more
about
encoding,
but
this
time
not
about
five
part
encoding.
Instead,
let's
talk
about
encoding
of
the
file
content
itself.
Consider
this
text
file.
When
you
take
this
text
file
and
you
migrated
compare
for
us
to
get
and
you
open
it
on
Windows.
It
might
look
like
that.
So
what
just
happened?
Well,
as
you
probably
know,
tough
words
are
supports
automatic
line
and
in
conversions
for
utf-16
and
Unicode
files.
A
So
that
means,
when
you
check
out
our
youtube
16
file
on
Windows,
it
will
generate
control
line,
treat
endings
and
on
UNIX
approach,
generate
line
feed
endings.
Unfortunately,
git
does
not
support
YouTube
16
files.
Instead,
it
handles
these
files
as
binary
files,
and
that
means
it
will
all
these
binary
files.
They
will
contain
the
line
ending
as
defined
on
a
migration,
and
how
do
you
define
the
line
endings
in
a
migration?
Well
again,
you
use
a
client
spec
and
a
client
flag
is
a
field.
A
You
don't
you
don't
realize
that
because
2007
is
long
longer
longer
on,
but
we
are
migrating
source
code
that
has
a
history
of
more
than
20
years,
and
so
we
run
into
these
old
revisions
and
we
need
actually
to
load.
We
need
to
load
them
in
order
to
put
them
and
to
get,
and
if
your
file
is
damaged
like
that,
then
you
won't
be
able
to
download
it
with
a
p4,
command-line
client.
A
You
won't
be
able
to
download
it
with
the
people
of
Israel
client
and,
of
course,
you
won't
be
able
to
download
it
with
g4.
In
all
these
clients.
You
will
get
this
error.
Translation
of
file
encountered
a
fire
content,
failed
near
line
1
and
just
a
little
side
note.
So
what
does
it
mean?
The
problem
is
that
that
perforce
adds
a
byte
order
mark
to
utf-16
files
in
2007
and
pre-2007
files.
A
So
all
your
data
is
properly
migrated
to
get,
unfortunately,
because
of
some
design
decisions
within
get
P
for
this
patch
is
only
applied
when
you
pass
the
desert,
where
both
option
I
discussed
that
with
the
maintainer
and
yeah
we,
we
agreed
that
this
is
probably
the
best
option,
because
we
don't
want
to
change
too
many
things
and
get
p4
for
this
fix,
and
this
fix
is
again
scheduled
for
the
next
get
version.
So
I'm
pretty
excited
about
that.
A
Okay,
the
next
topic
I,
want
to
talk
about
our
branches,
implementation
of
branches
in
purpose
and
and
get
is
completely
different
in
perforce.
A
branch
is
more
or
less
just
a
directory
that
you
copy
to
and
from
files
in
get
all
the
branches
are
organized
in
a
graph,
and
that
makes
the
migration
of
branches
pretty
complicated.
A
Get
before
actually
has
a
branch
report,
but
it
did
not
work
well
for
me
and
that's
why
I
implemented
poor-man's
branch,
abort
and
I
will
show
you
what
I
mean
by
that
in
a
first
step.
I
import
purpose,
branches
branch
directories
as
individual
get
branches,
as
you
can
see
here,
I
have
a
master
branch
that
I've
imported
and
a
release,
branch
that
I've
bought
it
and,
as
you
can
see,
both
branches
have
no
connection
at
all.
It
means
if
you
would
merge
one
of
these
branches.
A
So
in
the
next
step.
Second
step
I
create
a
copy
of
my
branch.
My
release
branch
here
and
I
call
this
copy
P
for
history
release.
I
will
show
you
later
on
what
why
we
need
that
in
a
third
step,
I
squashed,
all
the
commits
of
the
release
branch
into
one
commit
and
I
rename
the
branch
squash
to
release
in
a
fourth
step,
I
create
a
new
release
branch,
but
this
time,
I
branch
off
master,
so
I
have
the
connection
between
release
and
master
and
then
I
move
all
the
changes
from
the
squashed
release.
A
A
Why
do
we?
Why
do
we
migrate
history?
Anyways?
We
want
to
learn
from
the
history
and
an
engineer
might
look
a
certain
source
code
line
and
to
learn
what
how
the
source
code
line
was
developed
and
if
he
looks
at
the
source
code
line
in
the
release
branch
and
the
bottom
of
the
screen,
then
chances
are
that
he
will
enter
up
in
the
X.
Commit-
and
this
commit
doesn't
tell
him
too
much
because
because
it's
in
the
end,
it's
a
lot
of
changes
wash
together
in
one
commit.
A
However,
I
at
a
note
into
this,
commit
that
the
developer
should
look
into
the
p4
history.
Release
runs
for
more
details
and
that's
what
the
engineer
can
actually
do.
He
can
switch
to
the
people,
release,
branch
and
then
looked
for
the
particular
line
that
he's
interested
in
and
then
he
will
learn
all
the
details
about
this
line.
A
A
A
Many
people
realize
that
problem
and
came
up
with
the
same
extensions
to
get
to
to
solve
the
problem.
So
there
are
exemptions
that
are
called
get
annex,
get
fat,
get
media
and
more
recently
get
LFS
and
get
LFS
being
the
most
interesting
one.
From
all
these
options,
as
you
learned
just
yesterday,
git
LFS
is
natively
supported
by
github
and
that's
awesome,
because
it
makes
it
very
easy
to
set
up
git
repositories
with
LFS
support.
There
is
no
special
setup
required,
it
just
works,
but
how
does
get
LFS
and
most
of
the
other
options?
Actually
work?
A
I
want
to
give
you
a
little
reminder
of
that.
So,
in
a
git
repository
you
have
a
gate
attributes
file
and
in
this
cat
attributes
file
you
define
which
files
in
your
posit
ori
are
large
binary
files
and-
and
these
are
the
files
that
you
want
to
use
out
of
s4
and
instead
of
the
large
binaries,
get
LFS
stores,
just
a
pointer
in
the
git
repositories,
and
this
pointer
points
to
a
file
server.
It
actually
contains
the
large
binaries,
that's
pretty
much
how
get
out
of
s
works
and
menu.
A
A
A
A
You
can
also
define
the
extension
of
the
files
that
you
actually
want
to
store
in
LMS
in
this
case,
I
want
to
store
mp4
files
in
other
ves
and
then
I'll
get
before
that.
It
should
actually
push
these
files
to
the
LFS
server
right
away.
That's
more
or
less
a
debugging
option.
If
you
run
the
migration
for
the
first
time,
you
want
to
disable
that
so
you
actually
see
what
files
would
end
up
in
LFS.
A
But
here
we
want
to
do
the
real
thing,
so
we
set
it
to
true
and
if
we
push
the
large
files,
you
of
course
need
to
target
where
to
push
these
large
files.
So
we
need
to
add,
I
get
remote
and
then
get
LMS
goes
off
and
or
get
before
goes
off
and
makes
the
migration.
It
will
automatically
generate
the
proper
gear
attributes
file
to
tell
git
which
files
are
stored
in
LMS.
A
However,
as
I
said,
we
have
repositories
that
have
20
years
of
history
and
they
contain
a
lot
of
files,
and
so
what
file
extensions
should
should
I
pick,
unfortunately
justifying
the
file
extensions
that
did
not
work
well
for
me,
so
I
added
another
option
and
it's
called
large
file
compressed
fresh
hold.
So
what
do
I
mean
by
that?
A
With
this
option?
Get
before
will
take
a
file
from
perforce
will
compress
it
and
it
will
check
if
the
if
the
compressed
size
of
the
file
is
larger
than
this
given
threshold,
and
then
it
will
store
the
file
in
get
LFS
and
I
found.
That
200k
is
a
pretty
good
indicator
for
large
files.
For
for
me,
because
I
mean
imagine
if
you
have
a
source
code
file
and
you
compress
it,
and
it's
still
true
and
Kadem,
it's
a
pretty
big
source
code
file.
So
it's
probably
something
that
should
not
be
stored
and
get.
A
A
Okay,
the
next
topic
too
many
files-
there's
a
famous
quote
from
us
or
was
the
inventor
of
git,
and
he
brought
get
fundamentally,
never
really
looks
at
less
than
a
rule
repository.
So
what
does
he
mean
like
by
that?
Well,
when
you
have
a
git
repository
with
a
working
directory
of
like
a
hundred
thousand
files,
then
get
will
pretty
much
for
most
of
the
operations.
It
will
look
at
these
files
and
at
each
one
of
them.
A
So
if
you
have
a
lot
of
files
in
a
great
repository,
then
your
gate
operations
tend
to
get
slow
and
a
lot
of
files
is
read
like
a
hundred
thousand
there's
a
lot
of
files,
so
a
hundred
thousand
rather
still
works
a
million
files,
not
so
much.
So
what
can
you
do
about
that?
First
and
foremost,
you
can
exclude
undesired
files.
A
Let's
assume
I
mean
we
all
are
big
fans
of
the
octo
cats.
So
at
some
point
in
the
past
we
added
all
our
favorite
AutoCAD
pictures
to
the
repositories,
that's
great,
but
your
cats.
They
are
not
really
part
of
the
project.
You
can
build
tests
and
run
the
product
without
the
octocat.
So
you
might
not
want
to
have
them
in
your
final
git
repository,
so
you
should
exclude
them
and
again,
how
can
you
exclude
them
with
the
proposed
clients
back
in
a
client
spec?
A
But
sometimes
this
is
not
enough.
You
get
repository
is
still
too
big.
So
what
can
you
do
about
that?
Well,
you
can
move
your
third-party
code
out
of
the
get
repository
that
might
sound
obvious
to
you,
but
purpose
is
used
in
a
different
way,
at
least
in
our
company
many
of
our
teams.
They
put
all
the
stuff
of
a
certain
project
into
the
purpose
repository,
so
all
third
party
code,
all
dependencies,
everything
and
what
we
recommend
to
them
is,
first
of
all
using
a
use,
the
native
package
manager
of
your
environment.
A
But
some
programming
languages,
for
instance
C++,
don't
have
a
package
manager
and
we
use
a
lot
of
C++,
and
in
this
cases
we
recommend
to
use
get
sub
modules,
and
this
is
especially
true.
If
you
don't,
you
want
to
compile
this
stuff
in
the
sub
module
every
time,
then
someone
who
has
a
very
good
idea
and
it
works
great
for
us.
Although
one
word
of
advice,
we
do
not
recommend
to
nest
sub
modules
because
that
gets
complicated
very
quickly,
so
you
should
always
have
only
one
level
of
sub
modules.
A
But
of
course,
sometimes
we
have
third
party
components
that
have
large
binaries
and
we
don't
want
to
have
these
large
wineries
in
our
good
sub
modules.
So
we
use
our
other
factory
again.
We
zip
them
up
into
a
package
and
upload
them
to
the
corporate
artifactory
server,
and
then
we
set
up
our
build
and
dependency
scripts
to
download
them
whenever
they
are
needed
and
that
works
great
for
us.
A
Unfortunately,
even
with
both
of
these
tricks
or
positive
advices,
it's
not
enough-
our
repositories
are
still
too
big.
So
what
can
you
do?
Well,
you
can
extract
components
if
you
have
a
project
that
has
more
than
100
thousand
files.
Chances
are
that
you
can't
find
a
sub
component
in
this.
These
hundred
thousand
files.
However,
this
refactoring
is
usually
pretty
hard
and
some
often
times
the
development
teams.
A
Don't
have
the
resources
to
do
these
extensive
refactorings
and
if
you
were
factored
and
you
would
take
out
a
part
of
the
source
code,
then
I
really
want
to
yet,
and
it's
super
important
that
you
did
to
make
sure
that
you
have
independent
components
that
do
not
share
the
same
pace
of
development.
So
what
do
I
mean
that
by
that
well
consider
source
code
and
tests?
A
You
always
want
to
have
these
two
components
in
one
repository,
you
don't
want
to
slip
them,
because
whenever
you
change
something
in
a
source
code,
it's
very
likely
that
you
will
change
something
in
the
test
as
well,
and
you
don't
want
your
developers
to
make
two
commits
for
one
change.
This
will
make
it
hard
to
track
change
and
will
annoy
your
developers.
So
don't
don't
do
that.
A
A
So
again,
the
large
files
or
the
big
number
of
files
is,
is
a
known
problem
in
the
gate.
Community
and
many
people
try
to
solve
that
and
here's
another
idea
how
to
solve
that.
It's
called
Watchmen
Watchmen
is
a
demon
to
monitor
a
file
system
changes.
It
was
developed
by
Facebook.
They
use
Watchmen
to
make
their
source
control
system
mercurial
scale.
So
how
is
this
useful
well
by
default?
Get
asked
the
file
system
for
changes.
Imagine
you
have
1,000
files,
then
get
asked
400,000
questions
and
that
can
take
some
time
with
Watchmen.
A
A
A
Okay,
so
to
sum
that
up
all
these
technical
challenges
that
I
just
described
the
biggest
one
is
really
the
number
of
files.
So
if
you
migrate
repositories
from
perforce
to
get
off
on
any
other
a
puzzle
from
any
other
source
control
system
to
get.
This
is
really
the
thing
that
you
should
have
an
eye
on
so
reduce
the
number
of
files
in
your
git
repository.
In
order
to
make
your
developers
happy.
A
So
much
about
the
technical
challenges,
but
how
about
the
non
technical
challenges?
Well,
as
you
all
know,
git
is
a
distributed
version,
control
system
and
many
of
the
engineers,
or
at
least
at
our
company
many
injured
after
engineers
haven't
used
this
to
build
version
control
systems.
Yet
they
have
used
centralized
version
control
systems
and
they
are
used
to
the
concept
and
these
centralized
version
control
systems.
It
starts
with
these
very
simple
things
like
hashes.
What
are
these
hashes
I
mean?
A
They
are
used
through
consecutive
numbers
to
identify
a
certain
version
of
their
code,
and
now
they
get
these
weird
hashes.
And
then
there
are
things
like
the
staging
area.
Caphis
doesn't
have
something
like
that,
so
they
are
confused
by
that
and,
of
course,
since
kid
is
just
a
buted,
they
will
prick
pretty
quickly.
They
will
get
in
touch
with
Forks
and
remotes,
and
this
will
be
weird,
so
they
they
learn
that
they
can
push
their
codes
to
different
locations.
A
Yeah,
it's
something
it
might
be
natural
to
you,
but
it
takes
some
time
to
wrap
your
head
around
all
these
concepts
and,
of
course,
at
some
point,
they
run
into
a
problem
with
git
and
then
a
new
Stack
Overflow
searched
the
internet
and
they
will
find
a
solution.
And
of
course
the
solution
includes
a
git
rebase,
and
you
know
where
this
will
go
to
and
all
these
new
concepts
in
get
they
enable
developers
to
follow
new
workflows.
A
A
very
prime
prime
example
is
really
future
branches
in
other
source
control
systems
like
perforce,
it's
not
really
possible
to
have
future
branches
because
setting
up
a
branch
is
such
a
such
a
big
amount
of
work,
and
and
for
that
reason
the
developers
have
never
thought
of
using
a
branch
for
every
single
feature
offer
every
single
back
fix.
They
do
so
again.
They
need
to
wrap
the
head
around
and,
of
course,
pour
requests
are
an
awesome
workflow
to
our
developers
or
have
first
developers.
A
They
are
used
to
have
write
access
if
they
want
to
change
something
in
some
other
teams
code
but
Perkis.
They
don't
need
direct
write
access,
but
it
takes
some
time
to
to
understand
these
workflows
and
even
if
two
people
have
grasped
the
concepts-
and
they
know
the
workflows
get-
has
a
new
user
interface,
and
actually
it
has
many
user
interfaces.
You
can
interact
with
git
on
github
and
will
get
up
desktop
app.
A
You
can
act
into
a
cricket
with
sorcery
and,
of
course,
you
can
act
into
equity
it
with
the
very
powerful
command
line,
and
this
is
rare,
also
got
a
little
bit
of
pushback
with
the
command
line.
So
some
of
our
developers-
they
just
don't
like
to
use
the
command
line
and
ask
me:
are
we
in
the
eighties
again
what.
A
To
summarize
that
all
these
challenges
are
adaptive
challenges
and
they
are
really
really
hard
and
rerun
into
them
and
you
will
run
into
them,
probably
as
well.
So
what
did
we
do
about
that?
Well,
we
tried
to
start
a
movement.
First,
we
established
a
get
up.
Expert
seems
there's
a
team
of
people
who
are
getup
enthusiasts,
who
know
how
to
use
git.
You
know
how
to
use
git
up
and
who
know,
most
importantly,
how
to
what?
What
are
the
right
workflows
and
how
to
work
with
with
git
and
get
up
in
a
very
efficient
way.
A
Then
we
created
a
Q&A
page
in
our
company
network
that
people
can
use
to
ask
questions
about
git
and
where
they
can
get
an
answer
within
minutes
and
of
course,
then
we
provide
hands-on
training
for
the
first
projects
that
migrate
and
especially
for
the
bigger
project,
because
if
you
help
to
be,
if
you
have
people
to
be
more
practice,
then
they
will
actually
spread
that
knowledge.
They
will
share
it
with
other
peers
and
they
will
convince
other
peers
for
you.
So
we
try
to
grant
to
create
a
git
fanbase.
A
Second
use,
LMS
for
large
files,
it's
really
great!
It
works
on
all
platform
platforms
and
yeah.
We
it's!
It's
awesome.
Third,
reduce
the
file
number
of
files
in
your
git
repositories.
This
will
make
it
will
make
it
very,
very
much
faster
and
therefore
your
developers,
much
more
happy
and
last
but
not
least,
start
a
movement.
Take
your
developers
and
help
them
to
solve
their
problems
with
get
show
them
how
they
can
be
more
productive
with.
Yet,
if
you
get
that
across,
then
the
get
virus
will
spread
itself
and
thanks
for
listening.
A
Okay,
there
are
many
reasons.
Let
me
start
with
a
very
obvious
one:
I
mean
if
you,
if
you
go
to
any
university,
what
do
the
people
use?
They
use
kid
and
no
one
eats
other
magnets
university
use
perforce.
So
it's
a
and
the
people
use
kit
and
they
want
to.
You
is
good,
so
it's
an
advantage
to
get
talent.
I
mean
many
of
my
friends.
They
would
say:
okay,
the
shop
uses
perforce
I,
don't
wanna
you
prefer,
so
they
don't
start
at
a
certain
certain
company.
A
A
A
Okay,
question
is:
how
long
did
the
migration
take
so
right
now
it's
ongoing
and
we
established
some
processes
to
to
make
a
migration
really
easy,
so
it
yeah
right
now
it's
a
matter
of
days.
Really
the
main
thing
is
the
restructuring
of
the
repository,
so
we
need
to
work
with
the
teams
to
to
move
their
third-party
components
into
the
appropriate
places
and
that
that
is
what
takes.
A
Yes,
that's
the
thing
that
takes
the
longest
and
when
they've
done
that,
then
running
it
before
is
really
a
thing
that
takes
a
couple
of
hours
and
then
you're
done.
But
what
we
usually
do
at
least
right
now
is
that
we
we
migrate
the
repositories
to
get,
and
then
we
have
a
cron
job
that
updates
you
suppositories
every
night
so
that
the
teams
have
they.
They
continue
to
work
in
perforce,
but
they
have
the
git
repositories
with
updated
source
code
there
every
day,
and
we
do
this
so
that
they
can
play
with
git.
A
They
can
try
their
workflows
and
so
that
they
can
report
problems
early
on
because
yeah
we
I
mean
we
want
to
make
our
developers
more
productive
and
you
don't
want
to
get
into
their
way
doing
their
work
right
and
as
soon
as
they
tell
us.
Okay,
we
are
comfortable
with
the
get
workflows
and
everything
works
as
as
expected.