►
Description
This session, hosted by Patrick McKenna of GitHub, features some of the "greatest hits" from discussions in an internal-to-GitHub Slack channel (called #git-users) over the last year. The tricks & tips cover everything from plumbing commands and workflow advice, to thoughts on designing new Git tooling.
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
Hello:
everyone,
my
name
is
Patrick
McKenna
I
work
at
github.
It
came
to
my
attention
recently,
actually
I.
My
titles
probably
misstated
on
the
website.
I,
don't
really
care
about
that.
But
if
anyone
does
on
the
data
scientist
there,
so
today's
presentation
is
loosely
titled
greatest
hits
from
ask
it
core.
That's
slightly
misleading
I
want
to
explain
the
idea
behind
it,
so
I
work
at
github
and
we
employ
a
couple
of
the
core
maintainer
of
git
and
the
only
reason
I'm
mentioning.
That
is
because
it
makes
things
really
handy.
A
When
you
have
a
question
about
git,
we
may,
among
the
hundreds
of
internal
slack
channels
that
we
have
there's
one
that
is
a
pretty
nondescript
name.
It's
just
get
users,
but
it's
pretty
cool
for
everyone
who
works
there
to
be
able
to
jump
in
that
channel
anytime.
They
have
a
question
that
they
have
been
able
to
figure
that
out
themselves
and,
as
you
can
imagine,
there
are
a
lot
of
people
who
work
here
who
have
quite
a
bit
of
get
knowledge
already.
A
So
so
it's
really
great
to
be
able
to
go
to
somebody
who
really
is
an
expert
now.
That
said,
this
is
not
intended
as
a
tutorial
for
a
group
of
people
who
would
be
very
much
at
home
in
the
contributor
summit
right
now.
So
if
you're
here,
courgette
maintainer,
for
example,
this
is
probably
going
to
be
a
pretty
boring
talk.
That's
that's
not
the
intended
audience.
A
I'll
go
over
my
expectations
in
just
a
second
I
also
realize
it's
a
little
bit
difficult
sitting
and
listening
to
anybody
for
30
to
40
minutes
right
after
lunch,
so
I'm
not
going
to
be
terribly
offended
as
some
heads
go
on
desks,
I
get
that,
and
it's
also
there's
not
just
one
single
overarching
narrative
to
this
presentation.
So
if
you
fall
asleep
and
wake
up
five
minutes
later,
we'll
probably
have
moved
on
to
the
next
thing
already.
So
you
can
just
pick
up
from
there.
A
A
So
what
are
my
assumptions
about
the
audience
here
that
you're
comfortable
with
command
line?
Get
you
don't
need
to
be
using
it
exclusively
I've
spoken
with
a
number
of
you
already
who
use
get
gooeys
of
one
flavor
or
another?
No
need
to
be
ashamed
of
that
or
anything.
That's
totally
fine,
but
I
do
assume
some
proficiency
with
command
line,
get
that
you
understand
the
basics
of
its
internals,
so
it's
fundamental
object,
types
and
so
forth,
and
that
you're
familiar
with
shell
scripting,
at
least
at
a
high
level.
A
So
if
that's
just
to
give
you
a
general,
a
good
general
sense
of
what
I'm
expecting
from
everybody
else
out
there
and
if
you
have
more
specific
questions
afterwards,
I'll
be
available
just
sitting
in
the
back.
So
if
you
want
to
come
up
to
me
personally
and
then
chat
about
something
I'm
more
than
happy
to
talk
further
with
you,
this
is
also
kind
of
a
tricky
audience
always
planned
for
it's
like
the
long
tail
of
the
distribution
of
like
git
users.
Right
if
it's
a
roughly
Gaussian,
we
have
a
long
tail
here.
A
So
there's
a
wide
variation
in
terms
of
like
level
of
background,
so
I'm
trying
to
hit
the
sweet
spot
and
there
all
right.
So
the
first
thing
I
want
to
go
over
is
just
simplifying
some
common
tasks,
and
this
is
going
to
be
relatively
straightforward
here,
I
think.
But
if
there
are
questions
out
there
by
all
means,
ask
them
you
can
follow
along.
A
If
you
like,
just
with
whatever
kind
of
scratch,
git
repos
you
have
on
your
own
machine,
there
aren't
going
to
be
any
particular
ones
that
I'm
using
for
the
purposes
of
today's
talk,
so
I'm
not
going
to
ask
you
to
clone
anything.
But
let's
start
with
one.
That's
that
came
up
it's.
How
do
I
know
what
commits
were
added
to
a
given
branch
that
I
just
pulled
from
so
there's
a
couple
of
sumption
x'
baked
into
this
right
here,
but
assume
during
the
course
of
your
workflow.
A
You
you've
gone
into
some
particular
repository,
just
type
git,
pull
say
you're
on
master
I'm.
Assuming
a
lot
of
you
know
conventional
uses
of
get
right
here,
of
course,
and
you
want
to
figure
out.
Okay,
so
I
see
this
printout
of
things
that
just
got
a
fetch
down
from
the
server,
but
what
commits
were
actually
just
added
to
say
the
master
branch
if
I
was
on
master
I,
typed
pull
and
the
usual
arrangement
master
tracks.
A
So
that
might
look
something
like
this
right
here,
so
first
check
to
make
sure
that
there
is
an
argument
actually
past,
it's
not
an
empty
string
and
if
so
assume
that's
the
name
of
a
branch
and
if
there's
no
argument
passed,
then
we're
just
going
to
go
ahead
and
assume
that
you
mean
head
and
again
so
I'd
assume
everyone
knows
what
what
head
is
here
and
if
they're
for
questions
on
that
by
all
means.
Please
raise
your
hands,
okay,
so
the
next
thing
we
need
to
do.
A
We
need
to
actually
generate
the
list
of
new
commits
all
right
and
we're
going
to
use
a
plumbing
command
called
get
rev
list
rich
your
hands
if
you've
used
this
command
before
it's
the
smattering.
There's
always
like
that
half
hand
up
to
which
Mel
I
don't
know
if
you
used
half
the
command
or
but
okay.
So
what
does
get
rev
list
so
it
generates
and
traverses
commit
graphs
you're
not
going
to
be
using
it
much
in
your
day-to-day
life
with
get
on
the
command
line.
A
So
what's
the
general
syntax
for
commits
that
are
reachable
from
a
and
but
not
B,
it's
going
to
look
like
this
as
one
incantation
get
rev
list
a
caret
B,
so
a
and
B
here
are
committed.
So
if
you've
come
across
this
phrase
before
it
means
anything
that
can
ultimately
resolve
to
a
commit,
so
it
could
be
a
commit
object
itself
could
be
a
branch,
it
could
be
a
tag
and
so
on
and
so
forth.
A
There's
an
alternate
syntax
here,
get
rev
list,
B
double
dot.
A
I
would
definitely
recommend
using
the
former,
though
the
the
latter
is
kind
of
cryptic
that
ordering
or
means
exactly
the
same
thing
as
what's
on
top,
but
at
least
the
the
caret
symbol
there
in
certain
languages
and
environments
actually
means
like
a
logical,
not
operator.
So
I
think
that's
clear
to
some
people
that
say:
I
haven't
seen
any
other
place
where
the
mm
means
not
be
ante.
So
so
the
sake
of
clarity,
I'd
recommend
the
former.
A
So,
in
our
case,
what
are
a
and
B
actually
going
to
be
a
is
going
to
be
the
commit
to
which
branch
currently
points
and
B
is
the
commit
branch
pointed
to
before
you
last
pull
all
right.
So
how
do
we
specify
the
commit
that
branch
used
to
point
to?
That's
that?
That's
probably
the
part
here
that
people
are
least
familiar
with
I'm,
guessing
based
on
just
personal
experience
and
chatting
with
others.
So
there's
this
special
syntax
at
symbol,
curly,
brace,
N
and
n
here
is
an
integer.
A
A
So,
where
did
that
ref
point
one
time
ago,
two
times
ago
and
so
on
and
so
forth,
so
in
our
use
of
get
rev
lists,
we're
going
to
look
at
something
like
this
show
me
the
list
of
revisions,
the
list
of
commits
that
are
on
branch,
wherever
branch
currently
points
but
are
not
on
wherever
branch
pointed
one
time
ago,
before
the
last
time
it
moved
I
mean,
incidentally,
I'm
going
to
be
making
these
slides
all
available
too.
So,
don't
feel
like
you
need
to
copy
everything
down
verbatim.
A
So
that's
that's
useful,
because
I
think
there
are
a
lot
of
times
in
a
given
day
or
certainly
within
a
given
week
where
people
will
ask
this
question.
It's
like
alright
I
realized
I
just
got
a
bunch
of
updates
on
master,
but
what
did
I
actually
just
get
there,
and
it
is
actually
printed
out
for
you
that
this
information,
when
you
as
right
after
you
type,
get
pulled
by
default,
but
but
not
in
a
nice
format.
Just
like
this,
so
some
related
advice
be
careful
with
that
convenient
syntax.
A
The
@
symbols
so
I
mentioned
I
was
going
to
come
back
to
this
because
it
can
be
pretty
cryptic.
So
there
was
a
line
like
this.
This
is
actually
taken.
This
of
this
line
used
to
exist,
I
forget
in
what
github
repository,
but
it,
but
it
was
there
and
some
Engineer
came
along
and
looked
at
it
and
they
said
you
know
what
the
hell
are,
all
those
app
symbols.
What
does
that
mean
and
that's
a
totally
reasonable
question
if
you
haven't
seen
it
before
it's,
it's
not
self-evident.
A
Yeah
I
know
real
answer:
yeah,
that's
one
of
my
favorite
lines
from
the
chatroom.
Yes,
so
this
is
coming
from
a
corgi
maintainer
right,
then
tongue-in-cheek,
of
course
I
said
yeah.
But
the
idea
is
these
are
not
obvious
right,
so
you
don't
necessarily
want
to
to
include
them,
certainly
not
in
your
in
your
scripts.
Not,
but
just
so
you
know
the
@
symbol
with
nothing
else
after
it
is
short
for
head
and
the
@
curly
brace
you
is
at
upstream.
A
So
that's
that's!
What's
technically
going
on
there,
but
another
opinion
expressed
by
a
different,
different
maintainer.
So
using
then
scripting
is
a
horrible
idea.
Don't
use
don't
use
this
kind
of
shorthand,
which
is
really
nice.
Maybe
if
you
want
to
save
a
few
keystrokes
on
the
command
line,
but
if
it's
in
a
script
use
the
long
form
of
option,
switches
and
so
forth,
yeah
get,
as
we
all
know,
can
be
tricky
enough,
as
is
all
right.
A
So
there's
no
reason
to
just
make
it
even
harder
make
scripts
reader
friendly
where
we're
possible
and
again
this
is
advices
coming
from
people
who
build
I
work
on
get
on
a
daily
basis.
Too
and
so
they're
finding
it
a
little
cryptic
points,
so
you
might
actually.
This
is
actually
a
diff
taken
from
full
request
that
updated
that
particular
line
and
whatever
script,
that
was
to
make
it
somewhat
more
readable
and
that's
definitely
a
practice.
A
I
would
recommend
sticking
to
okay,
so
I
wanted
to
go
over
a
few
things:
tips
for
integrating
with
git,
and
what
does
that
mean?
That's
a
very
generic
phrase.
Integrating
with
get
there
just
a
few
cool
features
that
I
don't
think
most
people
know
about
I,
certainly
didn't
until
I
read
that,
and
one
is
how
you
can
add
some
metadata
to
branches,
and
the
second
has
to
do
with
using
exclude
patterns
in
external,
tooling,
say
scripts
of
one
sort
or
another.
A
So
what
do
I
mean
by
add
mated
metadata
to
a
branch?
There's
this
nice
option
switch
to
get
branch
edit
description,
give
it
a
branch
name,
and
it
will
pop
up
in
your
editor,
and
you
can
go
ahead
and
add
whatever
text
you
like
in
there.
So
this
is
really
handy
because
human
beings,
like
developers,
we
oftentimes,
think
in
terms
of
branches,
and
you
try
to
capture
some
meaning
within
a
given
branch
name
at
least
I'd
recommend
you
do
certainly
don't
just
put
Patrick's
branch
or
Saturday
experiment,
or
something
like
that.
A
You
know
give
your
branches
meaningful
names,
but
sometimes
you
want
to
put
a
little
bit
more
on
there.
Maybe
a
sentence
or
two
describing
what
it
is
that
you
intend
to
actually
do
on
this
branch,
and
you
might
have
some
tooling
that
is
going
to
be
looking
at
different
branching
branches
and
looking
for
some
kind
of
metadata
like
this,
and
this
data
is
then
written
to
get
and
config
and
the
nice
thing
about
it
is.
A
It
follows
renames
and
it's
deleted
when
your
branch
is
deleted
as
well,
so
it
gets
going
to
clean
up
after
itself,
and
this
is
actually
a
very
good
use
case
for
changing.
What's
in
git,
config
config
is
meant
to
be
extensible
for
a
lot
of
third
party
use
cases.
So
if
you
ever
find
yourself
trying
to
write
any
kind
of
tooling
your
home-brewed
stuff
for
your
your
own
interests
or
some
part
of
larger
larger
project,
git
config
is
very
much
an
okay
place
to
dump
some
extra
information.
A
Think
for
things
like
this,
the
next
thing
I
wanted
to
cover
is
using
exclude
patterns
in
scripts.
So
what
do
I
mean
by
exclude
patterns?
I
mean
the
kinds
of
things
that
are
going
to
show
up
in
your
git,
ignore
files
or
just
get
in
so
exclude,
and
the
case
anybody's
not
sure
what
the
difference
between
those
two
is.
Git
ignore
files
are
typically
as
part
of
the
repositories
they
go
in
your
commit
history
and
so
forth.
Get
info
exclude
is
a
place
that
lives
just
locally.
A
But
it's
nice
when
you're
say
building
a
testing
script
to
make
sure
that
your
test
scripts
aren't
going
to
go.
Look
at
whatever
dummy
files.
You
have
lying
around
that
they're
actually
going
to
respect
whatever
exclude
patterns,
you've
defined
for
the
project
and
it's
of
course
possible
to
re-implement
the
logic
behind
gets
excluded
patterns.
But.
A
And
you're
just
asking
for
extra
work,
so
I
do
it.
So
the
essential
plumbing
commands
you
want
to
know
about
here
is
get
check
ignore,
followed
by
a
path
name
alright.
So
this
is
going
to
return
path
name
if
it
matches
one
of
the
exclude
patterns.
So
you
can
either
pass
this
a
single
filename
or
you
can
pass
it
a
directory,
and
then
it
will
list
anything
any
files
in
that
directory
that
are
part
that
are
matched
by
an
exclude
Mattern.
A
Now
this
does
have
a
few
problems
with
it:
there's
no
recursive
option
for
wildcard
searches,
so
if
I
want
to
so,
if
you're
looking
at
this
assume
that
git
ignore
includes
star
sample
dot
py
if
I
type,
this
command
you'll
see
I
get
check,
ignore,
plug-in,
slash
star,
it's
going
to
tell
me
okay.
Yes,
there
is
a
file
that
fits
that
exclude
pattern
at
the
top
level
of
plugins.
A
But
if
there's
one
nested
one
layer
deeper,
it's
not
going
to
return
that
and
there's
no
option
switch
for
check,
ignore
to
tell
it
is
recursively
descend
through
all
directories
and
find
everything
so
that's
kind
of
a
pain,
because
that
means
you
need
to
actually
list
every
top
level
and
subdirectory
of
that
you
might
use
in
your
testing
scripts,
there's
a
somewhat
better
option
to
oh
there's,
a
couple.
Other
restrictions
I
want
to
point
out.
You
can't
filter
against
the
custom
again
or
file
check.
A
A
It
is
there,
but
it's
not
listed
on
the
index,
so
we
can
solve
those
first
and
third
issues,
though
right
not
having
that
recursive
option
and
having
a
command,
that's
actually
listed
on
get
SCM
when
we
use
get
LS
files
with
the
others
flag,
and
this
is
going
to
show
all
untracked
files
and
it
is
going
to
work
recursively
as
well.
So
to
give
you
an
example
from
another
repo,
do
we
happen
to
work
with?
A
We
have
a
one
repo
I
spend
a
lot
of
time
in
has
a
git,
pre-commit
hook
on
and
believe
I
believe
you
learn
actually
more
about
git
hooks
just
a
little
bit
earlier
today,
then
it's
going
to
do
some
Python
when
things
so
nobody
can
actually
commit
unless
they're
there
Python
files
pass
pepé
tenting
test.
So
it
looks
something
like
this
to
find
some
directories
where
your
Python
files
live,
pepé,
tis
a
command
to
just
do
exactly
what
I
was
mentioning.
They
check
some
style
conventions
for
Python
code.
A
A
That's
why
the
there's
the
pipe
there,
but
you
can
ignore
that
for
the
purposes
of
understanding
the
get
command,
and
so
this
is
useful
because,
for
example,
I
end
up
having
like
a
couple
scripts
that
I
keep
locally,
that
I
put
in
you
get
in
so
exclude
and
are
just
for
my
own
testing
and
maybe
I
even
jot
down
some
pseudocode
or
random
notes
and
I
don't
want
to
not
be
able
to
make
a
commit.
Just
because
I
wrote
a
note
to
myself
and
some
file
that's
supposed
to
be
excluded
from
the
project.
A
So
there's
that
now
the
next
thing
I
wanted
to
come
to
is
moving
history
between
repositories,
and
this
is
going
to
go
over
a
few
commands
that
we
also
touched
on
earlier,
but
I
checked
with
Chi
I.
Don't
think
he
actually
did
this
version
of
things.
So
this
isn't
going
to
be
redundant,
I,
don't
think,
but
let's,
let's
assume,
there's
a
scenario
where
you
have
two
separate
repositories
that
have
been
developed
independently.
A
Each
of
their
own
independent
history
haven't
referred
to
each
other
up
to
up
to
this
point,
and
what
you
want
to
do
is
take
a
subdirectory
that
lives
in
one
of
these
repositories
and
move
it
over
into
the
other.
So
you
don't
want
to
take
the
whole
thing.
You
just
want
a
subdirectory
and
you
want
to
move
it
into
some
target
repo,
and
you
also
want
to
preserve
the
history
as
well.
Okay,
so
this
is
the
use
case.
A
So
a
simplified
version
might
be
something
like
this
right
beforehand:
subdirectory
exists
and
source
after
exists
and
target,
and
why
would
you?
Why
would
you
be
doing
something
like
this?
You
might
have
a
repository,
that's
grown
to
include
a
bunch
of
different
code,
and
maybe
you
you've
decided
architectural
II.
We
want.
We
want
to
go
towards
like
the
micro-services
world
or
some
other
buzzword
of
the
day.
Whatever
reason
you
want
to
split
your
repository
up
into
multiple
components,
this
is
definitely
something
that
happens
on
a
semi-regular
basis,
I
think
certainly
at
large
organizations.
A
But
it's
a
one-time
operation
right,
so
we're
not
going
to
be
using
sub
modules
or
anything
like
that,
because
this
isn't
a
replacement
for
any
kind
of
dependency
management
system
or
package
management.
It's
just
a
one-time
thing
to
split
apart
a
large
project
and
we're
going
to
assume
that
subdirectory
doesn't
exist
in
the
target
repo.
It's
not
too
difficult
to
modify
this
example.
A
A
A
So
that's
that's
why
this
is
happening,
and
so
you
know,
if
you
run
this
operation
repeatedly,
you
should
get
exactly
the
same
results
every
single
time.
This
is,
of
course,
going
to
create
a
brand
new
set
of
sha-1
hashes
because
we're
having
to
artificially
reconstruct
history
and
we're
getting
different
trees
from
the
very
beginning
going
forward,
but
those
others,
those
hashes,
should
be
the
same.
A
Every
time
you
do
this
okay,
so
then
step
two
is
going
to
be:
let's
get
everything
in
that
subdirectory
into
the
target
repository
and
there
are
a
couple
different
ways
to
do
this:
we're
going
to
start
with
the
simplest
one.
So
in
the
target
repo
get
subtree
ad
prefix
and
the
sub
there
arguing
here
is
okay.
What
do
I
want
it
to
actually
be
called
in
the
target
repository
again,
we
were
going
to
assume
for
simplicity
that
we're
just
using
the
same
name.
A
A
Alright,
so
that
seems
pretty
straightforward
and
what's
going
to
happen
when
you
do
this,
it's
going
to
import
that
synthetic
history
and
it's
going
to
put
all
the
contents
sub-directory.
So
it's
pretty
much
exactly
what
you
want
right
there.
A
few
caveats,
though,
that
doesn't
may
not
work
in
exactly
the
way
you
expect
all
the
commits
will
be
there,
but
some
common
commands
that
you
might
want
to
use
afterwards
and
expect
to
work
in
a
certain
way.
Won't
necessarily
it's
a
git
log
I
think
is
the
best
example
of
this
so
assume.
B
A
Of
the
idea
this
is,
we
don't
want
to
just
bring
over
the
files
as
they
currently
exist.
We
want
their
full
history,
so
we
would
do
something
like
this
git
log
I.
Think
most
people
have
seen
this
this
invocation,
so
space
double
space
is
to
say.
Okay,
don't
show
me
all
commits
show
me
only
those
that
touch
the
patterns
after
the
double
dashes,
so
git
log
subdirectory
some
file
within
it
and
you're
going
to
see
a
commit.
That
looks
like
this,
and
this
is
the
commit
that
gets
created
when
you
ran
git
subtree
ad
okay.
A
So
that's
that
gives
you
a
lot
of
useful
information
right
there,
but
it's
actually
the
only
commit
you're
going
to
get
now
soon
file.
Whatever
that
is,
has
a
much
longer
history
in
the
first
repository.
You
would
expect
to
see
all
that
right
here
right.
That
was
the
whole
idea
of
bringing
over
all
the
history,
but
you
don't
at
least,
but
by
default,
an
adding
follow,
which
is
a
flag
that
one
would
typically
do
to
track.
Renames
of
a
file,
the
history
of
a
file,
including
renames,
is
not
going
to
fix
the
problem.
A
Others
are
kind
of
hacky
workaround
if
I
just
put
a
wildcard
before
the
file
name.
This
will
actually
output
the
list
of
all
the
history
of
the
file,
but
there's
some
problems
with
this.
It's
not
a
very
robust
solution,
because
what,
if
you
have
to
have
the
same
file
but
at
different
with
in
different
directories,
it's
going
to
catch
all
of
them?
It's
not
going
to
filter
in
quite
the
way
you
want
to,
and
that's
what
I
mean
by
some
of
the
limitations.
A
So
there's
a
second
way
to
do
this
actually
and
to
be
perfectly
candid,
I
I
did
not
figure
out
right
before
this.
Why
this
was
happening,
and
it's
still
something
I
want
to
do
so.
I
think
in
the
version
of
the
slides
that
I
end
up
posting
I'm,
going
to
put
in
a
better
explanation
for
this,
so
I
apologize
in
advance
for
not
having
that,
but
this
is
going
to
solve
that
problem
for
you.
A
A
So
let's
experiment
on
something
new
you're
going
to
add
as
a
remote,
whatever
your
source
repository
is
that
dash
F
flag,
just
means
fetch,
so
as
soon
as
the
new
remote
is
added
we're
going
to
fetch
from
it
to
get
all
its
references
on
all
its
objects
and
then
we're
going
to
use
a
special
version
of
the
merge
command
now
by
default.
Git
does
not
let
you
merge
branches
that
have
no
common
base
commit,
so
you
have
to
pass
it.
A
This
allow
unrelated
histories
flag
in
order
for
this
to
work,
but
once
you
do
that-
and
you
say-
ok
merge
into
my
new
branch.
The
branch
swear
I
made
that
sub
tree
in
the
source
repository
you're,
going
to
get
the
same
results
in
the
cent
terms
of
the
the
commits
that
are
actually
introduced
into
your
new
repository
and
something
like
git
log
path.
Name
is
now
going
to
work
as
expected.
So
you'll
not
only
see
a
commit
message
that
looks
like
this
one
earlier,
but
you'll
see
it.
However
many
others
existed
for.
A
So
some
general
notes
on
history-
manipulation,
which
is,
of
course,
a
tricky
thing
in
get
it's
very
powerful.
Of
course,
there
are
a
lot
of
different
ways
to
do
it.
Many
different
use
cases
so
just
a
few
notes
that
have
come
up
in
discussions
in
that
in
that
slack
channel
about
these
kinds
of
issues,
filter
branch
command.
Many
of
you
probably
heard
of
is
a
very
powerful
thing.
A
It
generalizes
better
to
processing
all
branches
instead
of
just
one
and
doing
many
other
fancy
things,
but
it's
notoriously
tricky
to
use
they've
been
notoriously
not
just
a
sense
of
like
ok
people
on
Stack
Overflow
campaigning
like
ok.
What
did
I
do
to
my
repository,
but
nope
even
people
who
would
get
on
a
day-to-day
basis
and
are
intimately
familiar
with
it.
It's
really
easy
to
screw
up,
so
just
be
very
careful
with
it.
Subtree
has
the
merit
of
being
a
lot
simpler,
but
there's
this
other
caveat
that
it
actually
lives
in
contribu.
A
Go
look
at
the
source
code,
forget
there's
a
contribs
up
directory,
and
so
this
is
not
going
to
the
subtree
command
by
default
ship
with
every
version
of
git.
You
can
always
get
it
if
you
just
build
from
source
and
a
lot
of
distributions
will
include
it
so,
for
example,
on
Mac
OS,
if
you
have
like
homebrew
installed,
get
your
going
to
have
the
subtree
command
included
as
part
of
that,
but
not
every
platform
is
going
to
get
it
by
default.
Filter
branch,
on
the
other
hand,
does
ship
by
default.
A
Let's
get
and
for
those
of
you
that
are
curious,
contribute
at
it
is
a
bunch
of
stuff
that
is
it's
like
not
quite
fully
baked
into
get
yet
stuff.
That's
been
pretty
well
developed
and
will
probably
get
included
at
some
point
in
the
future
into
main
all
versions
of
git,
but
is
not
necessarily
there.
Yet.
There
are
a
lot
of
interesting
commands
there.
A
So
a
couple
of
related
history
manipulation
tools.
They
just
want
to
point
out
no
stories
around
this,
but
just
a
few,
it's
of
like
wisdom
that
I
thought
were
kind
of
cool
and
that
you
kind
of
have
the
advantage
of
getting
when
you
have
a
chance
to
chat
with
people
who
are
working
on
git
on
a
regular
basis.
I'm
saying
in
one
of
these
cases
you
wanted
to
create
a
completely
new
history,
start
from
some
arbitrary
point
and
just
disconnect
from
everything
else
get
check
out.
Orphan
is
going
to.
A
Let
you
do
this
so
pick
an
arbitrary
point
in
your
commit
graph,
say
I'm
going
to
create
that
as
basically
the
start
of
time
and
move
on
from
there.
Some
people
may
choose
to
do
this
if
they're
migrating
over
from
say
some
other
version
control
system
to
to
get
they
don't
care
about
history
past
a
certain
point.
A
There
are
a
lot
of
potential
use
cases
here,
not
just
being
one
of
them
and
then,
if
you
want
to
do
an
abbreviated
history
of
sorts
like
just
I,
want
to
take
them
the
middle
chunk
of
the
commit
graph
or
something
that's
going
to
get
a
little
hairier.
We
definitely
don't
have
time
to
go
over
a
full
fledged
example
of
that.
A
A
It
really
doesn't
have
a
notion,
though,
of
a
commit
being
made
on
a
particular
branch
right
branches-
references
more
generally,
our
conveniences
for
humans
to
be
able
to
understand
a
directed
acyclic
graph
of
commits,
but
people
often
want
to
think
of
oak.
It
should
know
that
I
was
on
this
branch
when
I
made
this
commit,
really
doesn't
I
mean
and
being
able
to
internalize.
That
I
think
will,
to
a
very
mild
degree,
perhaps
take
away
some
frustration
when
you're
trying
to
figure
something
out.
So
that's
important
to
bear
in
mind.
A
Another
thing
that
somebody
figured
out
git
is
not
going
to
expand
built-in
commands
when
you
use
them
as
aliases.
So,
for
example,
if
I
try
to
create
a
git,
alias
that
uses
the
name
of
a
command
like
branch,
for
example,
but
with
some
other
flags,
so
that
whenever
I
type
git
branch,
it's
going
to
be
branch
with
those
additional
flags.
That's
not
going
to
work
interesting
bit
of
history.
A
This
apparently
was
debated
many
years
ago
by
gate
Corps
like
should
we
allow
people
to
create
aliases
that
have
the
same
name
as
built-in
commands,
and
this
was
actually
a
case
of
get
saying.
No,
because
we
don't
want
people
to
hurt
themselves,
which
I
think
a
lot
of
people
think
is
contrary
to
the
pattern
of
giebler.
It's
like.
Yes,
it's
an
all-powerful
tool,
just
be
careful.
A
If
it
hurts
don't
do
it
so
I
thought
that
was
kind
of
kind
of
interesting,
but
if
you
ever
run
into
problems,
creating
your
own
aliases
make
sure
that
you're
not
trying
to
alias
the
name
of
an
actual
built-in
command.
If
you
want
to
be
writing
your
own
scripts
that
are
going
to
be
doing,
get
objects
check
out,
get
SH
set
up
this
little
scriptlet,
as
it's
called
it'll
help
you
out
in
a
number
of
different
ways.
A
It
takes
care
of
a
few,
sometimes
problematic
environment,
depending
on
what
kind
of
operating
system
you're
working
on
and
includes
some
helper
functions
to
like
make
sure
that
you're
in
a
valid,
get
repository.
Your
version
of
get
actually
understands
and
takes
care
of
some
other
plumbing
tasks
that
anybody
who's
really
scripting
and
working
directly
with
get
ought
to
be
doing
this
just
has
it
for
you.
So
this
that's
a
again
just
go.
Look
at
the
git
source
code.
A
That's
one
of
the
things
that's
included
if
you
ever
want
to
contribute
to
get
I'm
get
still
operates
with
the
mailing
list
right.
So
there's
like
a
mirror
of
git
on
github,
for
example,
but
they
don't
accept,
pull
requests.
Somebody
did,
though,
create
this
pretty
sweet
web
app
to
go
ahead
and
make
it
easier
to
start
trying
to
contribute
to
get
core.
A
If
you
haven't
heard
of
this
before
I
highly
recommend
that
you
check
it
out,
I
actually
gave
a
presentation
on
it
at
last
year's
I
get
merged
conference,
but,
broadly
speaking,
it
really
makes
merge.
Canta
the
pain
of
merged
conflicts
go
down.
I'm
I'll,
leave
it
to
you,
as
for
for
outside
reading,
to
go
ahead
and
figure
out
more
about
it.
But
what
it
basically
lets
you
do
is
is
walk
back
if
you're
trying
to
merge
two
branches
and
figure
out
where
conflicts
originally
occurred.
A
So
it's
going
to
walk
the
commit
graphs
along,
say
two
branches
that
you're
trying
to
merge
and
say
hey.
These
are
the
pairs
of
commits,
like
you
know
this
many
days
back
on
each
branch
for
the
this
particular
conflict
first
got
introduced
and
you
would
solve
these
conflicts
one
bit
at
a
time.
So,
rather
than
dealing
with
one
giant
merge
conflict
at
the
end,
you
get
to
deal
with
the
conflicts
as
they
come
up
as
you're
traversing.
This
commit
graph.
Now
it
does
this,
but
it's
also
very
quick.
It's
surprisingly
efficient.
A
It
uses
some
git
bisect
like
algorithms
to
achieve
that
efficiency,
and
it
has
a
bunch
of
really
cool
ways
to
of
let
of
how
you
save
the
end
results.
So
if
you
want
to
just
use
this
as
a
tool
to
deal
with
nasty,
merge
conflicts,
you
can
do
that
if
you
want
to
do
that
and
save
intricate
interesting
versions
of
your
history
that
include
how
you
resolved.
All
of
that
you
can
do
that
and
perhaps
coolest
of
all
you
can
save
a
partially
resolved.
A
Merge
conflict,
push
it
to
your
favorite
git
hosting
service
and
let
somebody
else
work
on
it.
So
if
you
have
a
particularly
nasty
merge
conflict
that
say,
you
know
how
to
resolve
in
part,
but
but
not
completely.
You
can
fix
part
of
it
with
git
I
merge
push
your
results
up.
Somebody
else
can
pull
it
down
and
then
continue
and
you
can
go
from
there
so
being
able
to
save
the
state
of
a
partially
resolved.
Merge
conflict,
I
think
is
really
rad.
So
there's
my
he
has
not
paid
me
for
this.
A
A
So
that's
a
that's
everything
for
today's
talk.
I
think
we
have
a
little
bit
of
time.
Oh
yeah,
we
got
a
some-some
amount
of
time
left
so
I'm
happy
to
stick
up
here
for
questions
or
if
anyone
wants
to
approach
me
individually
afterwards,
you're
more
than
welcome
to
I'll,
be
here
both
today
and
tomorrow.
But
thanks
for
listening
I
realized.
You
have
probably
the
toughest
time
of
day
to
keep
your
eyes
open
and
I
haven't
seen
so
many
heads
on
tables.
So
thanks
for
that.
B
A
A
A
There
is
an
emerged,
a
straight
so
to
work
on
so
di.
That's
why
you
need
to
pass
that.
Allow
unrelated
histories
flags,
so
that
get
knows
not
to
look
for
a
merge
base.
It's
just
it's
adding
in
those
files
but
Brandon
and
constructs
a
new
tree.
It
doesn't
try
it
gate.
Key!
There's
no
merge
base
for
it
to
go
back
to
to
try
to
work
from.