►
From YouTube: Lightning Talks - Git Merge 2017
Description
Check out 3 quick lightning talks from Tamir Gefen, Meredith L. Patterson, and Santiago M. Mola.
Tamir Gefen presents a case study on moving to Git from IBM Rational ClearCase, including challenges; how to resolve them; some technical tips and lessons learned (including insights).
Meredith L. Patterson discusses the use of Git as a blockchain-like primitive for the delivery of humanitarian aid in a stored-value network. She'll also talk about git as a primitive for delay-tolerant design, and what that implies for P2P technologies and the developing world.
Santiago Mola discusses the development of go-git, a Git library written entirely in Go. He'll introduce the library and share some use cases.
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
We
are
with
a
team
of
experts
who
provide
the
consultancy
and
develop
atom
tool
for
gear.
Clearcase,
Jenkins
get
up
get
loud
and
a
bit
back,
etc,
etc,
and
today
I
am
going
to
share
some
a
quick
case
study
of
how
we
hope,
one
of
our
customers
to
migrate
away
from
clear
gift
to
get
that's
before
I'm
getting
started,
I'd
like
to
quickly
ask
you
by
wetting
your
hand
if
you
have
a
child
of
clear
days,
oh
great
okay.
A
A
Okay,
so
when
we
talk
to
the
customers,
we
firstly
ask
them
and
we
ask
ourself
also
if
we
have
to
switch
tools,
is
it
really
necessary?
So
we
ask
them
so
we
actually,
we
actually
got
three
main
reasons
why
they
decided
to
switch
tools.
The
first
one
was
the
first
one
came
from
the
management
of
the
senior
managers.
They
wanted
to
cut
a
slice
to
cut
off
a
license
in
spicing
and
they
just
wanted
not
to
pay
for
it.
It
also
involved
in
tenancy
post.
A
The
second
reason
was
from
the
end:
users
is
I
wanted
to
to
make
it
more
easy,
and
actually
it
came
from
the
you
know.
The
junior
developers,
who
was
with
get
only
the
they
got
experience
it
would
get
from
the
universities
or
college
and
I
just
wanted
to
to
work
with
the
tool
they
are
already
familiar
with.
And,
lastly,
it
came
from
the
IT
department,
so
they
wanted
to
consolidate
the
organization
into
one
tool.
A
They
actually
had
another
SEM
tool,
not
this,
but
they
just
wanted
to
to
do
it
to
make
it
all
consolidated,
so
they
decided
to
switch
to
and
then
a
you
know,
we
we
keep
talking
to
them
and
we
and
we
were
trying
to
to
map
all
the
other
relevant
challenges
when
we
start
moving
the
a
to
a
new
tool
and
actually
I'd
like
to
share
with
you,
seven
seven
main
challenges
that
we
face,
the
first
one
we
ask
ourselves,
these
tools
are
really
different
and
they
in
the
next
slide.
I
will
talk
more
about
it.
A
The
second
challenge
was
how
to
how
to
train
100
developers
and
how
to
let
them
get
prepared
to
use
annual
a
brand
new
system.
The
next
challenge
was
how
to
how
to
how
to
train
the
develop
develop,
how
to
how
to
help
the
developers
to
start
with
a
new
concept.
Should
we
should
we
set
up
a
new
and
you
flow,
and
next
it
comes
the
challenge
of
the
ideas
in.
In
that
case
they
were
the
work
with
eclipse,
so
they
asked
us
how
they
can
work
with
get
and
acquit.
A
So
we
all
know
it's
possible,
but
it's
one
of
the
challenges.
The
next
one
was
a.
What
about
the
history?
Should
we
just
take
the
whole
history,
or
should
we
just
take
a
few
snapshots
or
labels,
including
case
it's
a
big
question
and
the
next
one
was
about
the
administrators,
how
to
train
them,
how
to
how
to
give
them
the
ability
to
to
operate
gear,
to
be
able
to
to
cope
with
troubleshooting
and
so
forth,
and
the
last
one,
but
not
least
we.
A
We
know
that
we
had
the
limited
and
short
timeframe
to
to
work,
and
we
we
had
to
think
about
it.
So
now
I
just
want
to
to
focus
on
a
onto
two
of
the
challenges
and
the
first
one
was,
if
you
remember
our
given
classes,
are
really
different
tools,
so
we
realize
that
they
are
not
so
different.
I
mean
there
are
some
similarities
and
there
are
also
some
differences.
A
You
can
see
some
of
the
similarities
about
the
product
structure,
the
branching,
the
permissions
and
users,
and
there
are
some
differences,
and
the
point
is
that
when
the
developers
realize
that
it's
not
so
it's
not
so
different,
so
it
helped
us
to
go
to
to
let
them
calm
down
and
in
the
be
more
proactive
and
to
help
us
to
help
them
to
move
to
get
okay,
then
the
next
one
that
the
next
day.
The
next
point
that
I'd
like
now
to
focus
on
is
it's
about
the
transition
itself.
A
So,
firstly,
I'd
like
to
talk
about
four
points
on
the
planning,
so,
firstly,
we
decided
actually
I
want
to
I
want
to
focus
on
four
main
points
on
the
planning.
The
first
one
is
the
two
to
decide
about
the
migration
strategy.
I
mean
if
we
take
the
whole
history
and
so
forth,
and
it
comes
in
to
serve
in
the
next
slide.
The
next.
The
next
point
it's
about
setting
setting
up
a
new
flow
and
I
believe
that
you
can
quickly
see
the
we
finally
define
from
them.
A
In
four
point.
Four
minutes
only
so
I'd
like
to
quickly
go
over
migration
strategies
that
we
finally
decided
on.
So
we
decided
not
to
take
the
whole
history,
because
we
realized
that
we
can
keep
clickers
alive
in
a
read-only
mode
and
we
do
not
necessarily
have
to
take
the
whole
history
I'd
like
to
quickly
show
you
what
we
decided
to
take
and
to
migrate
into
get.
So
actually
we
decided
to
take
the
latter.
A
That's
a
lot
of
real
life,
the
life
branches
only
and
also
take
four
labels,
which
we
context
so
I'd
like
to
quickly
show
you
what
we
technically
apply.
First
of
all,
we
we
just,
we
decided
to
we
decided
to
take
release
1.0
and
which
means
it
on
the
clear
side.
We
set
of
view
that
points
to
to
that
release,
and
we
and
we
just
created
the
new
D
triple,
and
then
we
and
then
we
copy
all
the
data
into
the
fresh
repo
and
we
you
know
we
did
we
and
then
we
applied
the
first
commit.
A
Then
we
checked
out
to
a
new
branch
and
get
named
out
1.1,
and
then
we
went
again
to
the
click
aside
to
set
up
a
lot
L
1.1.
We
just
copied
all
the
data
into
the
repo
commit
again
and
now
we
have
a.
We
have
another
branch
with
the
whole
data
inside
then
we
decided
to
to
put
another
tag
we
list
to
the
river
the
first.
A
The
first
reason
was
to
be
able
to
branch,
to
branch,
to
split
out
and
then
set
up
a
branch
that
we
will
see
soon
and
the
second
module
to
keep
another
point.
If
we
want
to
branch
out
to
split
out
in
future
and
to
take
another
branch
out
of
how
to
deliver
so
we
just
do
the
same,
and
then
lastly,
we
just
go.
A
Ok,
I'd
like
to
quickly
show
you
the
result
and
the
some
lessons
that
we
learned
and
some
tips
so
the
result
number
one.
The
licensing
cost
is
now
zero.
They
got
a
new
flow,
including
CI
and
the
CIE
CD,
and
the
issue
tracking.
They
were
able
to
show
the
learning
curve
and
get
because
you
know
developers
find
that
git
is
a
is
easier
to
learn
than
clearcase
and
I've
already
talked
about
the
CI
and
more
ok,
lesson
learned
so
I
think
I
will
five
five
points.
A
You
do
not
have
to
the
number
one
you
do
not
have
to
remove
the
whole
history.
You
can
just
decide
about
the
active
labels
only
and
it
can
take
you
much
less
time
to
move
all
the
data.
You
should
move
each
software
group
separately.
In
that
case,
we
we
had
five
different
groups,
so
we
just
we
started
with
the
first
one,
and
then
we
have
a
time
for
which
perspective
to
learn
how
to
do
it
more
quick
and
then
we
did
the
same
for
another
fall
good.
A
You
should
allocate
two
days
to
accommodate
developers
and
troubleshooting
on
the
day
that
they
are
moving
away
to
do
get
the
transition
is
an
opportunity
to
improve
the
software
processes.
I
have
talked
about
the
ICD
then,
so
the
transition
should
be
planned
by
a
person
who
really
knows
both
clearcase
and
get,
and
you
should
create.
You
should
define
success
criteria
just
like
accepting
tests,
and
you
know
when
adjusting
as
a
developer,
who
who
have
to
decide
where
to
think
in
advance
about
about
unit
tests
and
before
he
applied
somewhere
feature
tips.
A
Okay,
you
should
you
should
define
a
comparison
table
of
translating
clickers
to
get.
It
helps
the
developers
to
get
started
very
quickly.
You
should
also
give
them
a
the
new
flow,
a
printed
diagram
and
share
it
with
them.
It
helps
to
count
them
down.
You
should
stray.
You
should
use
strong
and
reliable
infrastructures
and
last
one
beware
of
clickers,
evil,
twin
and
hard
links.
If
you
have
any
questions,
so
you
can
contact
me
here
on
the
whole
Bethel.
B
Alright,
let's
start
out
with
a
thought,
experiment
suppose
that
there's
some
kind
of
major
disaster
like
an
earthquake
or
hurricane
or
an
epidemic
and
after
the
initial
recovery
process
is
done.
You
know
everybody's
been
rescued
from
burning
buildings
and
everything
the
Red
Cross
comes
to
you
and
they
say
hey.
We
have
all
of
this
aid
that
we
need
to
distribute
to
people
who
need
to
rebuild
their
lives
and
we
need
to
figure
out
how
to
get
it
to
them.
B
You
know
we
could
just
turn
up
with
truckloads
full
of
cash,
but
you
know
this
got
tried
in
Iraq
and
lots
of
that
cash
got
stolen.
So
how
can
we
come
up
with
a
digital
system
to
deliver
money
to
people
who
are
in
need
of
it
in
emergency
situations?
Here's
the
catch.
You
cannot
assume
a
reliable
network.
B
Well,
this
is
not
actually
a
thought
experiment.
This
is
my
day
job.
So
this
all
started
back
in
2014
when
the
founder
of
the
company
I
work
for
Emerson
pan
was
doing
some
work
for
Doctors
Without
Borders
in
Sierra
Leone.
He
was
doing
some
IT
work
and
then
they
found
out
that
the
central
bank
was
about
six
weeks
away
from
running
out
of
money.
B
Now
they
were
paying
all
of
the
hospital
workers
and
other
health
care
workers
in
cash,
and
so,
if
they
didn't
have
any
bank
notes
they
weren't
going
to
be
able
to
pay
people.
Sick
people
would
wander
out
of
the
hospital
trying
to
find
food.
Everybody
would
you
know
everybody
would
get
infected.
It
would
be
an
even
worse
disaster
than
it
already
was.
So
there
were
several
proposals
for
what
to
do
a
couple
of
large
IT
companies
who
I
will
not
name
and
shame
on
video
suggested
hey.
B
Why
don't
we
just
build
something
in-house
and
then
we'll
come
out
to
Sierra,
Leone
and
roll
it
out
and
Emerson
said
no,
no,
no!
No!
No!
No
way.
We
can't
do
that
because
anything
built
off-site
is
not
going
to
be
sensitive
to
the
needs
of
the
region
to
how
people
do
business
here
we
need
to.
We
need
to
do
something
locally
and
what
they
ended
up
doing
was
they
found
a
local
development
shop
that
had
built
out
a
payroll
system
for
one
of
the
local
cell
phone
companies.
B
It
paid
people
in
cell
phone
minutes
because
those
are
a
pretty
common
alternative
currency
all
over
Africa.
They
also
had
you
know
quite
a
lot
of
buy-in
from
the
government,
because
you
know
there
were.
This
was
literally
a
life
and
death
situation
for
everybody,
so
the
government
actually
issued
a
presidential
decree
making
cell
phone
minutes
into
legal
tender.
So
they
took
this.
You
know
2,000
person,
payroll
system
and
with
a
lot
of
work
and
a
lot
of
Amazon
instances,
they
scaled
it
up
to
30,000
healthcare
workers
and
it
worked.
B
They
brought
it
in
on
time
and
for
many
of
the
people
that
were
being
paid
by
this
system.
It
was
the
first
time
in
their
lives
that
they
had
ever
been
paid
on
time
and
in
full.
It
ended
up
generating
a
lot
more
trust
in
the
system
that
had
ever
existed
before
and
and
the
system
is
still
still
running
today.
The
only
problem,
though,
is
we
also
need
a
system,
that's
going
to
work
offline,
so.
B
B
What
you
do
need,
though,
is
one
of
the
primitives
that
Bitcoin
also
relies
on
just
known
as
a
link
based
timestamp
chain,
so
that
image
on
the
slide
is
from
Wikipedia's
Wow.
Why
is
that?
Acting
like
that
yeah?
So
this
is
from
Wikipedia's
a
page
on
like
based
timestamp
chains,
you'll
see
that
at
every
step,
you've
got
documents
that
are
being
hashed
and
then
that
hash
is
hat
is
hashed
into
a
hash
tree.
So
this
ends
up
cryptographically
entangling
hashes
of
new
things
that
are
introduced
with
the
hashes
of
old
things
that
were
already
introduced.
B
You
know
the
value
of
a
new
timestamp
depends
on
the
values
in
previous
timestamps
and
it's
also
very
difficult
to
modify
them.
Does
this
sound
like
something
you're
already
familiar
with,
because
it
should?
It
is
a
link
based
timestamp
chain.
People
have
said
that
it
is
a
content,
addressable
file,
store
and
that's
true,
but
it
happens
to
be
implemented
in
the
form
of
a
link
based
timestamp
chain,
and
so
that's
what
we
use
and
it
turns
out
that
the
workflows
that
we
use
are
actually
remarkably
simple.
B
B
So
on
our
own
servers,
we
create
two
repos
for
each
user.
One
of
them
is
an
incoming
ledger,
money,
that's
being
sent
to
that
user
and
the
other
one
is
the
outgoing
ledger
for
that
user:
money
that
the
user
has
sent
to
somebody
else.
So
we
anit
these
empty
repos
and
then
we
clone
them
to
the
user's
device.
Now
we
use
limited
used
keys
for
signing
transactions
so
that
you
know,
for
instance,
if
your
phone
gets
stolen,
somebody
can't
just
you
know,
run
around
inside
a
bunch
of
transactions
as
you
indefinitely.
B
Eventually
they
will
run
out
so
once
that's
in
place,
suppose
that
I
want
to
send
you
some
money.
Well,
if
we're
not
online,
that's
okay,
because
our
phones
can
still
pair
over
NFC
or
Bluetooth
or
or
ad-hoc
Wi-Fi.
So
we
exchange
public
keys
and
we
each
verify
that
the
public
key
that
we
got
from
the
other
person
has
been
signed
by
the
mountain.
Oh
and
master
key.
So
we're
using
some
web
of
trust
here
as
well.
So
I
want
to
send
you
some
money,
so
I
clone
your
incoming
ledger
off
your
phone.
B
You've
got
a
little
Android
service
speaking
the
git
protocol
on
your
phone.
That
will
expose
your
incoming
ledger
when
somebody
needs
to
clone
from
it
or
push
to
it
so
to
create
the
transaction.
I,
create
a
new
branch
and
then
I
add
my
own
outgoing
ledger
as
a
remote
for
it
then
I
create
the
transaction
as
just
a
regular
file.
We're
using
H
ledger
format
because
it's
very
easy
to
parse,
and
then
we
staged
that
file.
B
We
need
to
settle
the
transaction
that
we've
made
so
that
the
so
that
the
ledger
be
up
at
the
mothership
of
Chios
stays
up
to
date.
So
we
do
this
all
on
a
on
a
settlement
branch.
So
we
check
that
out
and
then
for
every
incoming
branch.
We
just
merge
all
of
those
transactions
in
verifying
the
signatures
as
we
go
along
and
we
sign
that
merge
commit.
Then
we
just
get
rid
of
the
branch.
We
do
the
same
thing
for
outgoing.
We
push
everything
back
up
to
the
mountain
OA
servers,
and
that
is
it.
B
That
is
all
we
have
to
do.
It's
a
ridiculously
simple
workflow!
It's
something
that
you
know
it's
something
that
even
a
newbie
developer
can
understand
very
quickly
and
I
think
this
is
really
the
the
strengths
of
using
well-established
protocols
as
primitives
in
this
way.
You
know
Karen
spoke
earlier
this
afternoon
about
how
other
kinds
of
how
organizations
that
aren't
software
organizations
can
use
git.
B
You
know
for
tracking
documents
and
developing
things
that
aren't
software
and
I'd
like
to
encourage
all
of
you
to
start
thinking
about
the
primitives
that
you
use
on
a
day
to
day
basis,
not
just
in
the
context
that
you
use
them.
But
how
can
you
use
them
elsewhere
with
the
right
kinds
of
primitives?
We
can
make
incredible
changes
in
the
world
get
happen
to
already
be
the
exact
primitives
that
we
needed
in
order
to
do
a
distributed
ledger
with
centralized
trust.
B
C
C
The
first
step
to
doing
this
is
analyzing
all
open
source
online
and
we
are
currently
analyzing
70
million
grid,
reaper
studies
that
all
github
repositories
that
are
not
Forks.
We
are
now
expanding
this
pipeline
to
analyze
more
than
60
million
repositories,
so
that
includes
github
orgs,
get
ripple
studies
coming
from
other
providers
such
as
it
love
or
the
packet.
C
So
this
is
a
task
that
is
very
intensive
on
get
usage.
So
what
do
we
use?
So
we
use
the
git
command
line.
Client
then
leave
get
to
or
J
get
for
the
JVM,
so
our
language
of
choice
at
source
is
go
so
we
chose
to
do
it
from
scratch.
We
created
go,
get
go,
get
disappeared,
go
implementation
of
git
I've
got
idiomatic
api's
for
wormed,
both
line
being
porcelain,
and
it
has
a
particular
focus
on
accessibility.
C
We
aim
for
it
to
be
compatible
with
leave
get
to
and
they
get.
We
are
still
not
there,
but
we
are
working
towards
it.
We
already
put
two
years
of
development
into
it.
So,
with
respect
to
extensibility
a
few
of
the
things
that
we
can
extend,
our
storage
backends,
those
define
whole
object.
References
configuration
are
stored,
we
have
by
default
either
in
memory,
storage
or
virtual
file
system
storage,
and
we
also
have
this
beautiful
system
abstraction
for
work
trees.
C
So
let's
go
to
our
use
case,
so
our
first
building
block
is
a
universal
get
mirror.
We
want
a
local
copy
in
our
cluster
of
every
is
repository
on
every
provider.
These
are
just
a
few
examples
that
we
are
working
also
on
self
costed,
good
rapport
studies
that
we
find
on
Google
and
so
on.
So
here
comes
the
first
problem
and
you
see
that
this
blue
repositories
are
Forks,
that
one
of
the
first
column
is
for
Clinton
see
the
but
majority
of
repositories
online
are
just
Forks.
We
store
just
the
health
for
non
Forks.
C
C
We
create
a
repository
for
its
initial
trauma
class,
so
here
we
have
an
example
of
a
Ripper
study,
fool
where
we
have
a
fork:
cold,
butter
and
mustard,
and
the
branches
share
the
same
initial
come
across.
While
another
branch
github
pages
share
are
different
in
excel
comic
has
so
for
its
reference.
We
push
it
to
a
local
repository
corresponding
to
its
initial
commit.
So
this
is
a
method
that
works
consistently
for
many
edge
cases
and
across
all
providers.
C
Finally,
there's
also
the
problem
of
storage
were
so
we
store
all
of
this.
This
is
quite
different
to
the
storage
of
get
providers
such
as
github
and
so
on,
since
we
are
oriented
to
a
full
repository
analysis.
So
when
we
open
up
a
story,
we
actually
open
it
for
reading
it
in
full
perform
some
analysis
on
this
whole
history.
So
we
use
a
distributed
file
systems
for
this,
such
as
the
affairs
or
Google+
direct.
C
The
good
thing
about
these
file
systems,
among
other
things,
is
that
they
have
high
throughput,
but
they
have
also
high
latency
for
every
input
output
operation.
So
when
we
want
to
analyze
a
full
git
repository,
we
have
to
open
a
few
back
files
open
a
few
reference
files.
We
have
to
open
some
loose
objects,
maybe
the
config
file,
so
the
latency
for
all
of
these
operations
are
top
and
it
becomes
a
performance
problem.
C
C
You
can
read
more
about
this
on,
on
our
blog
seen,
both
the
archiving
format
is
open
source
the
same
as
go
gate,
so
you
can
find
all
the
information
there
and
the
plantation
details
and
well
there's
no
time
for
questions,
but
if
you
want
to
discuss
any
of
these
further,
just
pick
me
outside
and
we
can
continue
talking
about
it.
Thank
you.