►
From YouTube: An Improved Workflow for Submodules - Git Merge 2022
Description
Presented by Emily Shaffer
An overview of and update on Google's efforts to create an improved workflow with submodules, as announced on the mailing list in 2021.
About Git Merge:
Git Merge is dedicated to amplifying new voices in the Git community and showcasing the most thought-provoking projects from developers, maintainers, and teams around the world. Git Merge 2022 took place at Morgan Manufacturing in Chicago, IL on September 14th and 15th.
A
Just
like
Pono
said
it's
the
year
of
Linux
on
the
desktop
hi
everybody.
Oh,
my
God
I
am
so
excited
to
see
everybody
like
real
in
person
like
see
your
faces
at
a
real
conference.
My
goodness,
my
name
is
Emily.
Schaefer
I
lead
the
get
core
team
at
Google.
So
that
means
that
oh
I'll
talk
about
it
in
the
next
slide,
but
that
mostly
means
that
we
hack
on
git
Upstream
the
git
client
that
we
all
know
and
probably
love
I
hope.
A
Here,
there's
some
extra
details
in
the
speaker
notes
on
some
of
the
thornier
slides,
so
you
can
feel
free
to
pop
open
your
laptop
pop
open,
the
slides
have
a
look
or,
if
you're,
having
trouble.
You
know
understanding
me
or
anything
literally
I'm
reading
from
the
speaker
notes,
so
just
open
the
speaker,
notes
and
you'll
know
everything
I'm
going
to
say.
A
Okay,
so
let
me
introduce
myself
a
little
bit
further
I've
been
at
Google
for,
like
six
years
I
just
had
my
six
year,
Google
bursary
like
last
two
two
weeks
ago
and
I've
been
working
on
the
get
core
team
for
like
three
years
this
year,
I
actually
I
just
became
the
lead
for
that
team.
So
this
is
very
scary.
A
For
me,
the
get
core
team
means
that
we
work
on
the
get
client
Upstream
full-time
modulo,
whatever
kind
of
releasing
overhead
that
we
might
have,
and
since
I've
joined
we've
been
primarily
focused
on
making
git
work
with
huge
repositories
so
get
at
scale,
and
in
a
past
life
I
was
a
firmware
hacker
I
used
to
co-maintain
part
of
open
BMC.
If
anybody
has
heard
of
it
and
I've
I've
reformed
since
then,
but
I
really
haven't
let
go
of
like
some
other
things
like
my
deep
love
of
regular
expressions
and
so
on.
A
I
love,
regular,
Expressions
really
and
of
course
just
you
know
every
everything's
better
with
dog
pictures,
so
here's
an
obligatory
photo
of
override
he's.
My
dog
he's
the
best
dog
he's
very
good
okay.
So
what
is
a
sub
module?
We
might
not
all
be
familiar
with
the
term,
so
I'll,
try
and
explain
the
sub
module
is
the
get
term
for
referencing
one
repository
inside
of
another
repository.
A
A
It
might
kind
of
sound
like
a
pain,
but
it's
actually
really
helpful
if
you're
looking
for
repeatable
and
bisectable
builds
and
it
kind
of
helps,
you
avoid
some
other
supply
chain
attacks
like
you
might
think,
like
log4j
or
something
we
also
use
it
at
Google
for
performance
reasons.
So
we
have
some
very,
very,
very,
very
large
projects
which
kind
of
break
get
with
the
sheer
number
of
objects.
You
saw
the
folks
just
in
the
section
before
this
I
don't
know.
If
anybody's
ever
opened
that
Android
Source
tree
it's
big.
A
So
in
those
cases
we
might
want
to
split
some
parts
of
the
project
out.
So,
for
example,
a
really
simple
example,
you
could
think
is
some
like
non-code
assets
that
are
associated
with
a
really
specific
version
of
some
project.
So
you
could
think
like
the
Android
startup
movie
that
plays
when
you
install
is
it
12
Android
12
is
the
most
recent
something
like
that.
A
So
so
now
we
know
what
sub
modules
are.
Maybe
we
can
talk
a
little
bit
about
how
they
work
so
I'm,
going
to
start
with
the
basics,
which
has
nothing
to
do
with
sub
modules.
Actually,
it's
a
single
repository,
git
project.
Most
of
you
are
probably
familiar
with
this
I
really
hope,
especially
after
this
morning.
So
we've
got
the
git
directory.
This
contains
all
the
Machinery
forget
and
then
at
some
given
commit.
We've
got
the
work
tree
and
this
is
filled
with
some
like
files
and
directories
and
in
the
object
store.
A
A
So
we
can
take
a
look
first
at
the
file
system
and
we
can
see
that
inside
of
our
super
project,
skit
directory,
we
have
a
couple
of
other
git
directories,
so
each
of
these
will
contain
the
machinery
for
their
their
specific
sub-module
and
inside
of
the
work
tree.
We've
got
two
brand
new
directories
here.
We've
got
sub
1
and
sub
two,
so
these
are
actually
the
sub
modules
work,
trees
and
inside
of
these
sub
modules,
we
can
see
that
it
looks
pretty
much
like
any
other
git
project.
A
So
there's
like
a
DOT
get
file.
There's
some
files
and
directories
making
up
the
work.
Trees
looks
like
pretty
normal.
One
thing
that
I'll
note
is
the
the
dot
get
here.
It's
actually
a
file
that
contains
a
path.
It's
not
a
full
git
directory.
The
path
in
that
file
is
the
path
to
the
get
directory.
That's
up
in
the
Super
project.
Skit
directory.
This
kind
of
like
using
the
get
the
dot
get
file
rather
than
the
dot
get
directory,
is
familiar
for
people
who
might
have
used
like
get
worktree.
A
If
you
haven't
used,
Git
worktree
You
should
use
it.
It's
freaking,
great
okay,
so
it's
basically
a
pointer
to
the
actual
git
directory
and,
like
I,
said
that
lives
inside
the
super
project,
skit
directory
and
finally,
we've
got
this
dot
get
modules
thing.
So
this
thing
contains
some
metadata
that
you
need
to
generate
the
sub
modules
git
directories
at
clone
time,
so
it's
got
like
the
remote
URL,
the
tracking
Branch,
the
name
stuff
like
this.
A
So
we
can
also
see
how
these
are
represented
by
objects.
We've
got
these
two
special
things:
sub
1
and
sub
2.,
so
these
are
called
git
links,
so
that
basically
means
it's
not
just
a
tree
like
like
the
source
directory
will
be
represented
as
a
tree.
It's
actually
a
full
git
repository
and
we're
referring
to
it
by
the
the
currently
checked
out,
commit
ID,
so
we're
not
using
the
computed
Tree
ID
we're
using
the
full
commit
ID.
So
that
means
it's
got
the
author
data
and
history
and
blah
blah
blah
blah.
A
So
you
can
think
of
it.
Basically,
like
a
pointer,
it's
a
pointer
to
a
commit
in
the
sub
module
project.
These
sub
modules
are
independent
projects
from
the
super
project
and
each
one
has
its
own
commit
graph,
Object,
Store
and
so
on,
and
development
in
the
sub
module
can
happen
totally
separately.
The
super
Project's
pointer
to
it
just
kind
of
gets
updated
whenever
it
makes
sense.
The
super
project
does
not
track
the
tip
of
the
sub
module
Branch.
That's
important
and
some
modules
they're,
not
necessarily
for
everything,
they're,
not
great,
for
every
single
workflow.
A
So
there's
a
few
cases
where
they're
not
really
a
good
idea.
So,
for
example,
if
you
always
want
to
take
the
latest
from
a
dependency,
they
might
not
really
be
for
you.
So
in
this
case
you
know
that
you're
always
going
to
be
taking
the
bleeding
edge
and
you
don't
care
if
you
use
a
different
version
of
your
dependency
when
you're
bisecting
against
older
code.
So
probably
in
this
case,
you
would
really
just
want
to
use
a
package
manager,
the
automation
that
you
would
need
to
follow
the
tip
of
your
sub
module.
A
And
finally,
if
your
sub
module
really
doesn't
mean
anything
by
itself,
so
in
this
case
you're
like
probably
trying
to
have
like
a
perfect
monorepo
and
you're
just
using
the
sub
modules
for
performance
charting
right.
So
they
can
work
this
way,
but
they
actually
provide
a
lot
of
additional
flexibility
beyond
what
a
mono
repo
would
provide
and
that
extra
flexibility
can
be
a
pitfall.
So
you
should
probably
proceed
with
caution.
A
So
maybe
we
can
talk
about
what
it's
like
to
use
them
right
now,
so,
most
of
the
time
we
interact
with
sub
modules
today,
by
using
this
git
sub
module
command,
it
does
a
lot
of
different
things
that
can
help
manage
the
lifetime
of
your
sub
modules.
So
we'll
just
go
down
the
list
here.
Git
sub
module
ad
is
used
to
create
a
brand
new
git
Link
in
your
project.
A
So
this
takes
the
remote
URL
for
another
repository
that
you're
trying
to
make
part
of
your
super
project,
and
it's
only
used
once
during
the
lifespan
of
your
sub
module.
It's
kind
of
vaguely
similar
to
git
add
because
the
git
link
is
staged
after
you
run
it
and
the
changes
to
the
git
modules
file
are
staged,
but
it
doesn't
actually
populate
the
contents
of
your
new
sub
modules
work
tree.
A
So,
although
you've
got
some
of
the
stuff
that
you
need
there,
if
you
try
and
like
CD
into
your
sub
module
and
see,
what's
going
on,
it's
it's
empty,
there's
nothing!
There
get
submodule
init
is
used
to
create
git
links
for
sub
modules,
which
are
present
in
the
index,
but
they're
not
in
the
work
tree.
Yet
so
when
you're
cloning
a
project,
if
you
are
cloning
and
it's
got
sub
modules-
it's
not
really
going
to
tell
you
that
it
has
sub
modules.
A
A
So,
basically,
if
you
used
to
pull
from
github.com
some
project-
and
you
decide
okay
I'm
going
to
mirror
instead
I'm
going
to
use
this
mirror
at
git.kernel.org
some
project,
then
you
would
use
this
command
to
teach
the
submodule
the
new
URL
I,
don't
know
if
anybody
is
familiar
with
the
tool
called
repo.
That's
used
for
Android
development.
If
anybody's
got
some
hands
a
few
people,
you
know
repo
sync.
This
is
not
like
reposync.
This
doesn't
do
the
same
thing
as
reposync
at
all,
totally
different.
A
So
git
sub
module
update
that
is
kind
of
like
it
is
used
to
set
the
sub
module's
current
commit
to
the
one
that's
referenced
in
the
super
project.
So
sometimes
this
results
in
a
simple
git
checkout
in
the
sub
module,
but
sometimes
we
have
to
do
it
get
fetch
first.
If
the
sub
module
is
missing
the
commit
that
the
super
project
thinks
it
should
have.
Yes,
you
have
to
run
this
manually
simply
checking
out
another
commit
from
the
super
project,
doesn't
automatically
check
out
the
corresponding
commit
in
each
sub-module.
A
This
command
also
will
clone
sub-modules,
which
were
newly
added.
So
it's
really
easy
to
forget
to
run
it
when
you're
checking
out
a
commit
with.
You
know
some
new
sub
module
that
showed
up
in
the
the
recent
history.
There's
a
ton
more
of
these
git
sub
module
sub
commands,
but
the
last
one
that
I
wanted
to
touch
on
is
called
git
sub
module
for
each,
which
is
pretty
much
the
same
thing
as
like
xargs.
If
anybody's
used
xargs,
it
runs
the
command
that
you
provided
in
the
context
of
each
sub-module.
A
What
is
happening
so
all
of
these
files
are
actually
git
links
and
get
us
trying
to
tell
me
that
when
I
checked
out
commit
b556,
my
sub
modules
didn't
come
along,
so
they're
all
still
pointing
to
whatever
was
that
tip
before
and
to
be
fair.
If
I
had
run
git
checkout
Dash
recurse
submodules,
the
sub
modules
would
have
come
along
with
me,
but
it's
really
easy
to
forget
to
do
that.
A
When
I
run
git
status,
I've
got
all
of
this
modified
junk
here
these
are
the
sub
modules
and
so
they're
they're
modified
because
they're
pointing
at
the
wrong
place.
Okay.
Well,
this
is
this
is
easy.
This
is
an
easy
one.
I
know
how
to
get
rid
of
junk
I'm
going
to
use
my
favorite
Hammer
get
reset
Dash
hard,
I
love
it
I
use
it
all
the
time
totally
fine.
A
So
this
should
have
made
my
work
tree
perfect
and
sparkling
and
perfectly
clean
right,
no
I
guess
not,
so
it
didn't
do
anything
because
the
sub
modules
need
to
be
synchronized
to
the
super
project
commit.
We
might
remember
from
the
previous
slide
that
that
one's
good
submodule
update
and
because
I
ran
git
reset
hard
without
recurse
sub
modules.
It
looked
just
at
the
super
Project
work
tree,
and
it
said
oh
there's
nothing
to
do
here.
This
is
great.
It
didn't
do
anything.
A
A
So
that
means
really
we've
kind
of
got
a
set
of
commands
which
can
do
anything
that
we
might
want
to
do,
provided
we
know
exactly
how
to
use
them
and
based
on
you
know,
I
know
people
watched
Jacob's
talk
this
morning,
so
we
kind
of
understand
that's
how
get
started
out
too
back
in
2005.,
but
we've
come
a
really
long
way.
Since
then
I
know
not
everybody
might
call
it
usable,
but
using
its
porcelain
interface,
sure
it's
a
heck
of
a
lot
better
than
using
the
plumbing
commands
directly.
A
So
let
me
say
a
little
bit
more.
Like
I
said
this
was
touched
on
from
Jacob's
talk
this
morning.
Git
has
two
classes
of
commands:
we've
got
the
plumbing
commands
and
we've
got
the
porcelain
commands
these
porcelain
commands.
These
are
the
ones
that
we
use
every
day
like
get
ad
get
status,
get
push
so
on.
They
do
lots
of
different
kind
of
things
in
a
single
command,
depending
on
the
option
I'm.
Looking
at
you
get
checkout,
you
do
too
much
but
they're
like
pretty
easy
to
remember.
A
You
know,
but
many
of
these
commands
actually
call
lots
of
other
smaller
commands
and
they,
as
other
commands,
tend
to
follow
like
the
Unix
philosophy
that
we
should
do
only
one
thing,
and
we
should
do
it
really
well.
So
that's
commands
like
get
hash
object,
which
computes
the
hash
of
an
object,
shocking,
there's
tons
of
these,
and
you
too
could
use
your
git
repository
by
calling
just
these
Plumbing
commands.
A
A
So,
let's
talk
about
how
many
of
us
might
be
familiar
with
the
merge
commit
as
the
unit
of
review,
so
some
developer
might
make
a
handful
of
changes
in
their
own
or
on
their
own
in
separate
commits
and
when
they
ask
for
a
review.
The
entire
topic
branch
is
reviewed
all
at
once
and
later
it's
going
to
be
merged
all
at
once.
A
So
this
is
the
primary
GitHub
model,
pull
requests
or
gitlab
calls.
It
merge
requests
and
often
when
we
do
merge,
sometimes
we'll,
like
we'll
squash
it
all
together.
So
you
really
just
have
like
one
commit.
We
don't
really
see
all
these
little
things
but
whatever
so
we
know
that
all
of
these
individual
commits
exist,
but
when
they're
taken
out
of
context
with
each
other,
they
don't
really
make
a
lot
of
sense
by
themselves.
A
The
topic
as
a
whole
is
what's
interesting
to
review
with
some
modules
it's
actually
pretty
similar,
so
a
feature
might
require
commits
in
a
handful
of
sub
modules
and
the
super
project
commit
that
encompasses
the
full
set
of
commits.
Sorry,
the
super
project
commit
does
encompass
the
full
set
of
commits
that
are
required
to
complete
the
task.
So
in
this
example,
we're
going
to
add
a
new
feature,
so
we're
going
to
add
a
new
button,
we'll
make
some
style
changes
to
draw
it.
A
A
A
So
with
that
guiding
Concept
in
mind
that
we
can
treat
the
super
project
commit
kind
of
like
a
merge
commit,
we
can
start
to
be
a
little
bit
more
opinionated
about
the
workflow.
The
reason
that
git
submodule
XYZ
is
hard
to
use
is
because,
although
you
can
do
anything
with
it,
git
doesn't
actually
do
any
of
that
stuff
for
you,
but
now
that
we're
pretty
sure
we
know
what
a
good
luck
workflow
looks
like.
We
can
start
to
have
get
recurse
implicitly
in
a
predictable
way.
A
When
we're
changing
branches,
we
can
ensure
that
the
entire
work
tree
matches
the
state
that
the
super
project
commit
thinks
it
should,
when
we're
trying
to
check
out.
So,
presumably
we're
going
to
want
to
do
some
hacking
after
we
change.
So
we're
going
to
make
sure
that
the
sub
modules
also
have
a
branch
of
that
name
set
up
and
pointing
to
the
right
commit,
and
in
some
cases
this
might
actually
be
different
from
the
commit
at
the
remote
branch
of
the
same
name.
A
We
want
your
work
tree
to
be
clean
after
a
fresh
checkout,
and
we
want
it
to
match
the
state
that
the
super
project
thinks
it
should
have.
So,
if
necessary,
we're
going
to
point
the
local
branch
to
something
that
may
or
may
not
be
different
from
what
the
branch
of
the
same
name
points
to
Upstream
and
as
we
hack
in
the
sub
modules,
we're
going
to
keep
committing
as
we
go,
and
the
super
project
is
left
with
a
Dirty
Work
tree,
because
the
get
link
has
changed
so
before
we
switch
away
from
this
Branch.
A
We
need
to
you
know
just
like.
With
a
with
a
single
repository,
we
need
to
get
rid
of
the
Dirty
Work
tree.
We
need
to
make
some
commit
in
the
super
project
so
that
we
can
keep
track
of
that
change
during
fetch
over
the
course
of
the
super
project
history,
we
might
have
added
some
additional
sub-modules.
A
So
let's
say
that
after
you
fetched
somebody
added
a
new
source
dependency
Upstream,
we
should
clone
that
submodule
when
we're
fetching
again
in
your
local
copy,
so
that
the
newly
added
submodule
will
just
work
and
in
some
cases
the
sub
module
might
have
been
added
and
then
removed
again
later.
On
we
should
clone
it
anyways
and
that's
specifically
so
that
when
we're
bisecting
or
moving
around
in
history,
that
submodule
will
work
I'm
like
psyched
that
so
many
people
talked
about
bisect
earlier
today,
by
the
way
like
good
bisect
is
rad.
A
Okay,
rebasing
is
a
little
bit
trickier.
We
already
are
not
super
great
at
rebasing
merges
and
git,
but
we're
proposing
to
rebase
these
super
project
commits
which
we've
previously
stated
are
like
really
similar
to
merge
commits.
So
maybe
I
don't
know.
So,
let's
take
a
look
at
how
an
interactive
rebase
might
work.
A
The
super
project
commit
will
have
to
be
regenerated
at
every
set
of
sub
module
commits
because
the
git
links
will
be
different
after
they've
done
their
own
rebase
and
by
the
way,
even
though
I've
shown
it
for
an
interactive
rebase
here.
This
is
also
the
kind
of
thing
that
we
would
do
for
like
git
pull
Dash
r
git
push
is
easy,
though
we
really
only
have
one
thing
we're
worried
about
forget
push.
A
We
want
to
just
make
sure
that
any
sub
modules
that
we're
pushing
before
the
Super
project
we
want
to
make
sure
they
make
it
in
before
the
Super
project
commit
makes
it
in,
and
that's
so
that
we
don't
confuse
any
CI
that
might
try
and
pull
the
brand
new
super
project
commit
and
immediately
do
something
with
it.
So
I've
drawn
a
picture
here
of
the
bad
state
where
the
super
project
commit
is
Upstream.
The
sub
module
commit
is
not
pushed
all
the
way.
A
So
instead
we're
just
going
to
make
sure
that
the
sub
module
commit,
makes
it
all
the
way
to
the
server
and
is
fully
accepted
before
we
push
or
accept
the
super
project
commit
and
in
the
future,
some
review
platforms,
like
maybe
like
Garrett,
could
even
use
the
super
project
to
commit
itself
with
everything
in
an
un.
You
know:
unaccepted
state
to
synchronize
pushes
across
multiple
super
sub-module,
remotes
and
I
really
hope
that
nobody
from
the
Garrett
team
came
to
this,
and
here's
me
like
making
promises
for
them.
A
A
It's
a
really
big
project.
We
want
to
make
sure
that
we
don't
build
the
whole
thing
and
discover
that
it's
totally
unusable
so
we're
using
a
handful
of
small
implementation
stages
and
at
each
stage
we're
working
with
testers
inside
of
Google
to
find
out
whether
or
not
it's
working
for
them,
but
in
all
cases
actually,
even
though
we're
testing
with
googlers
they're
just
handy
they
just
live
near
us
all
of
our
testers
are
going
to
be
using
git,
that's
primarily
from
the
next
Branch
Upstream.
So
that
means
that
anybody
could
use
these
workflows.
Even
you.
A
It's
still
early
days,
like
I,
said
we're
still
working
on
the
basics.
So
right
now
we're
working
on,
ideally
allowing
somebody
to
make
like
a
one-time
drive-by,
take
it
or
leave
it
change
with
no
intention
of
iterating
during
review
or
working
further
on
the
project.
Afterwards,
maybe
you
like
find
a
typo
in
some
Doc
that
you're
referring
to
it,
doesn't
sound
like
much,
but
it
actually
gives
us
a
good
enough
start
to
get
a
little
bit
of
user
feedback.
A
So
for
now
it's
enough
folks
might
have
seen
some
related
changes,
making
it
into
git
lately
mostly
gated
behind
configs.
So
we
have
some
things
like
enabling
clone
Dash
recurse
sub
modules
to
turn
on
recursion
by
default,
which
I
mentioned
a
little
earlier,
allowing
branches
to
inherit
the
tracking
information
from
the
branch
that
they
forked
from.
A
But
in
this
case
it's
necessary
to
even
be
able
to
try
out
the
workflow
in
the
first
place.
Nobody
wants
a
workflow
where
the
initial
clone
takes
like
four
hours
or
more.
Does
it
sound
exciting
to
you?
Are
you
like
I
know
it's
complex,
but
like?
Are
you
jazzed
anyway?
Do
you
want
to
help?
Do
you
want
to
test?
Do
you
want
to
hack?
Do
you
want
to
do
anything?
I
have
some
links
in
the
slides
here.
You
can
do
a
little
bit
of
reading
and
get
up
to
speed.
A
You
can
chat
with
any
of
me
or
my
team
during
the
bi-weekly
IRC
stand-ups
on
Libera
chat,
so
I
listed
the
channel
and
the
handles
for
my
team.
We're
not
super
good
at
being
on
IRC
all
the
time,
but
we're
definitely
there
in
the
scheduled
stand-ups
every
other
week,
and
you
would
be
welcome,
of
course,
to
come
and
join
contribute
poke
holes
in
the
workflow
review
code,
write
patches,
change,
documentation,
write
blog
posts,
anything
anything
helps
everything
helps
and
if
there's
any
questions,
I
think
I
have
a
couple
of
minutes
to
answer
them.
A
B
This
is
all
really
cool
work.
I
was
wondering
considering
submodule
ux
one
of
the
things
that
would
be
really
nice
for
projects
that
use
submodules
of
you
had
a
fluent
way
to
act
upon
sub-modules,
so,
for
instance,
when
you're
looking
at
status,
if
it
could
recurse
into
the
actual
sub
modules
to
some
extent
and
allow
you
to
add
files
like
from
a
top
level
instead
of
having
to
operate
in
every
particular
git
directory.
I
know
that
this
is
really
complicated,
but
has
any
thought
been
given
to
those
kinds
of
things
so.
A
I
think
that's
one
of
the
later
changes
that
we
have
considered
for
good
status.
It's
a
little
bit
exciting
and
fun
to
implement,
because
I
think
we
get
to
do
some
some,
like
hook
out
and
like
call
status
in
each
sub-module
or
something
I'm,
not
sure
it'll
be
fun,
I'm,
pretty
sure
that
we
have
some
something
like
that
in
the
design
dock.
But
it's
been
a
while
since
I
looked
there,
so
please
feel
free
to
take
a
look.
C
A
In
the
pull
request,
workflow
so
I'm
going
to
be
honest,
we
did
mostly
design
it
around
the
gear
workflow.
So
let
me
think
for
a
second
I
think
you
would
be
pushing
to
your
own
fork
in
both,
if
that's
correct,
so
I
think.
As
long
as
the
sub
module
commit
is
present
in
your
fork
of
the
sub
module,
then
the
super
project
commit
should
be
able
to
push
to
your
fork
of
the
super
project.
But
that's
a
really
good
point
that
we
should
think
about
how
to
set
up
this.