►
From YouTube: 2020 06 10 GSoC Git Plugin Performance Project
Description
Google Summer of Code Jenkins git plugin performance improvement project office hours from June 10, 2020. See the meeting notes for topics.
A
A
B
So
for
today's
agenda,
the
first
thing
we
have
to
discuss
is
adapting
the
benchmark
and
go
inside
the
gitline
plugin.
So
mark
you
were
saying
yesterday
that
I
think
it
it's
it's
a
it's
an
issue
that
the
benchmarks
they
take
a
long.
They
take
a
long
duration
to
run,
and
if
anyone
is
changing
the
goat
for
anything,
it's
I
think
it's
unnecessary
for
the
benchmarks
to
run
right
now
for
every
build
that
we
create
for
every
pr
that
everyone
raises.
So
you
were
saying
that
we
should
change
change,
change
that.
B
A
No,
I
think
I
think
what
well
this
is.
This
is
a
great
chance
for
the
mentors
to
kick
to
to
give
help.
I
think
one
of
the
techniques
we
could
do
is
we
could
say,
put
in
the
jenkins
file
a
conditional
which
says
if
the,
if
the
jenkins
url
environment,
variable
is
ci.jenkins.io,
and
if
the
branch
is
master
then
run
the
benchmarks
or
we
could
also
say
if
the
branch
name
is
and
choose
a
name.
That's
symbolic
that
says
g-sock
you
know
g-shock
star.
A
If
it
matches
g-sock
star,
then
we
say
we'll
run
it
there
and
the
typical
pr's
won't
use.
That
name
and
therefore
won't
run
the
benchmarks
on
those
pull
requests.
So
I
think
we
we
absolutely
want
it
on
master
and
we
absolutely
want
it
on
your
pull
requests
so
that
that
means
we
need
some
conditional
logic
in
the
jenkins
file.
That
says,
if
we're
on
this
branch,
do
it?
If
we're
not
on
that
branch
or
we're
not
on
ci.jenkins.io,
don't
do
it.
A
That's
and
that's
something:
whoever
does
the
probably
reshab.
Actually,
when
you
write
the
the
entry
in
the
jenkins
file,
you
have
to
figure
out.
Is
there
a
way
to
do
a
wild
card
pattern
match?
I
think
groovy
has
wild
card
string
matching,
but
you'll
have
to
go
figure
that
out,
I
I
don't
remember.
I
always
have
to
go.
Look
it
up.
Okay,.
D
Yeah,
you
should
be
able
to
do
something
like
you
should
be
able
to
do
something
like
that.
I
mean
you
may
not
even
need
that
necessarily
I
mean
if
you
decided
that
master
and
then
like
some
gsoc
branch
name,
are
the
ones
that
you
wanted
and
that
then
that
would
work
or
maybe
you're,
perhaps
thinking
that
maybe
there'd
be
multiple
g
suck
branches
yeah.
My.
D
A
The
get
plug-in
is
somewhat
special
in
the
one
of
the
maintainers
runs
his
own
ci
infrastructure
and
cares
very
much
about
it,
but
that's
kind
of
weird
most
most
maintainers
actually
don't
run
their
own
dedicated
ci
setup
with
lots
of
agents
etc.
So
if
you
skip
the
jenkins
url
and
just
checked
on
branch
name,
that's
probably
still
already
good
enough.
B
Okay,
I'm
going
to
research
about
it
and
then,
if
I
have
some
doubts,
I'll
ask
great
okay,
so
then
the
next
and
the
next
thing
we
have
on
the
agenda
is
the
current
status
with
the
tasks
I
have
so
I've
been
working
on
the
gate,
redundant,
fetch
issue,
mostly
that's
where
I've
spent
my
time
first.
The
first
thing
I
did
with
the
fix
was
to
first
solve
the
current
issues.
We
had.
B
What
happens
is
that
we
we
use
this
api
clone
under
underscore,
and
this
is
essentially
git.
Init
plus
git
fetch
step.
It's
not
a
git
clone
actually,
but
it
it
gives
the
user
all
the
functionalities
a
clone
can
give.
So
that
is
why
so
we
we
do
this
first
and
then
we
have
another
another
git
fetch,
which
I
I
my
assumption
is
that
we
have
the
second
git
fetch,
because
we
want
for
an
example.
B
If
I
have
a
fork
repository-
and
I
mention
it
as
a
repository
url
and
if
I
have,
if
I
have
five
more
comments
in
it,
so
the
difference
I
can
in
the
comments
I
can-
and
I
can
get
that
through
the
belt
when
I'm
running
the
build.
So
that
is
one
of
the
possible
use
cases
I
could
understand
of
having
the
second
fetch,
and
so
this
is
the.
Why
mark?
Could
you
could
you
jump
in
here
and
explain?
B
A
I
I
think
the
second
fetch
is
a
terrible
accident,
most
likely
and
it's
an
accident
that
has
existed
for
a
very
long
time.
So
I
wish
I
could
give
you
a
better
answer.
Rashad,
it's
embarrassing
to
say
I
can't
give
you
a
better
answer,
but
I
suspect
that
second
fetch
is
accidental
or
accidental
is
too
strong?
Is
a
funny
word
for
it,
but
that
second
fetch
is,
is:
is
there
and
it's
been
there
for
a
very
long
time.
B
Yeah,
that's,
okay!
So
that's!
Okay,
that's
not
important!
I
think
solution
and
this
the
things
we
have
to
care
about
and
more
important,
so
I'll
I'll
show
the
fix
I
have
created
for
it.
So
the
fix
is
very
simple.
I
just
created
a
boolean
flag
and
if
we
are
cloning,
the
repository
for
the
first
time,
then
it's
true
and
we
basically
skip
the
the
second
fetch
if
we
have
used
git
flow,
get
in
it
plus
git
fetch
for
the
first
time.
So
this
is
the
solution
I
provided
at
the
time.
B
I
was
writing
the
proposal
now
the
things
we
have
to
consider
when
we
are
doing
when
when
we
are
fixing
this
issue
when
we
are
avoiding
the
second
fetch.
So
one
of
the
first
things
is.
One
of
the
first
thing
we
have
to
consider
is
the
possible
options
we
are
providing
with
the
first,
with
the
clone,
with
the
clone
behaviors
we
have
and
the
fetch
behaviors
we
have,
the
the
decoration
of
the
fetch
command
and
the
decoration
of
the
clone
command.
B
So
what
could
happen
with
when
we're
using
ordering
refspec
at
initial
clone
or
we're
not
using
it?
So
if
you're
using
honoring
refspec
at
initial
clone,
if
our
respect
is
narrow
and
if
we
are
and
if
the
second
fetch
is
being
ignored,
we
have
to
make
sure
that
wait.
A
second,
I
think
I'm
confused
here
if,
if
we're
using
on
a
ref
spec,
so
if
so,
first
of
all,
let's
let's
talk
about
if
we
are
not
using
on
a
rev
spec.
B
So
if
you're
not
unique
using
on
a
ref
spec,
the
git
clone
the
git
clone
api,
it's
it's.
It
basically
assumes
that
it's
going
to
fetch
all
the
branches
instead
of
even
if
I've
given
the
rev
spec,
it's
going
to
fetch
all
the
branches,
and
that
happens
because
we
couldn't
break
a
funk.
We
couldn't
break
an
existing
use
case
related
to
get
it
plug-in.
As
far
as
I
remember
mark,
that's
why
it
was
provided
there.
So
so,
then
we
are
not
honoring
refspec
and
we
have
a
so.
B
What
we'll
have
is
we'll
have
a
wide
ref,
spec
and
wide
means
that
we
will
be
fetching
all
the
branches,
so
we
don't
have,
even
if
you're,
avoiding
the
second
fetch.
It
doesn't
matter.
It
doesn't
matter
because
we
have
all
the
branches.
So
there
will
be
no
repository
data
loss
if
we
avoid
the
second
fetch,
but
only
only
when
we
could,
when
we
could
have
a
possible
scenario
where
we
could
lose.
B
I
possibly
could
lose
all
the
reps,
all
some
some
of
the
branches
or
some
of
the
data
I
have
so
this
is
the
first
thing
we
have
to
consider
when
we
are
creating
the
solution
and
when
we
are
creating
the
automated
automated
tests
we
have
to
test.
If
this
is
happening
or
not
questions
there,
because
I
think
I'm
not
giving
a
very
good
description
do.
Do
you
guys
have
questions
for
for
this
particular
scenario,
then
I'm
going
to
explain
the
next
scenarios.
I
figured
out.
A
D
B
So
because
of
that
unit
test,
I
understood
that
when
I'm
avoiding
the
second
fetch,
I'm
also
avoiding
some
of
the
the
behavior
which
we
provide
because
of
the
fetch
command.
So
so
what
I
did
to
make
sure
that
I'm
not
missing
out
anything.
I
create,
I
created
an
exhaustive
list
of
possible
behaviors
we
have
and
what
is
rated
to
get
loan,
which
is
getting
it
plus
fetch
or
what
is
rated
to
the
fetch
command
so
after
creating
or
that
list.
I
I
basically
listed
all
the
options
here
which
we
could
possibly
have.
I
unders
I.
B
What
I
could
understand
was
that,
with
the
fetch
command
we
provide
clean
before
checkout.
We
provide
prune
stale
branch,
that
is
pruning
the
branch,
and
then
we
provide
pruning
the
stale
tag.
Apart
from
these,
the
clone
command
and
the
fetch
command,
they
have
common,
they
have
common
options.
So
so
what
so?
B
The
point
here
is
the
point
of
highlighting
this
thing
is
that
I,
if
I
want
to
avoid
the
second
fetch
I
need
to,
I
need
to
add
these
behaviors
to
the
first
clo
or
to
the
first
call,
and
if
I
don't
do
so,
I
will
be
missing
out
some
of
the
additional
behaviors
which
we
will
be
providing.
So
those
behaviors
I've
found
out
is
clean
before
checkout,
it's
pruning,
both
the
branch
and
tag
so
with
clean
before
checkout.
B
I
think
it's
so
my
solution
to
this
problem
to
this
problem
is
to
basically
add
features
to
the
clone
api,
to
provide
all
the
features
which
are
missed
while
we
are
skipping.
The
second
fetch
call
I-
and
this
is
why
this
is
according
to
me,
a
good
solution,
because
we're
not
breaking
any
functionality,
any
compatibility,
I'm
not
changing
the
fetch
command.
B
So
this
is
why
I
chose
this
solution
and
so
to
implement
the
solutions.
Few
things
we
would
have
to
do
is
first
to
the
option
clean
before
checkout.
I
would
have
to
add
it
to
the
clone
step,
and
I
think
for
that,
it's
it's
very.
It's
pretty
simple,
because
the
gear
we
just
have
to
clean.
We
just
have
to
perform,
get
clean
for
this
option.
It
basically
cleans
the
the
working
directory
the
current
working
directory
right.
That
is
what
get
clean
does
so
for
to
to
migrate.
This
option.
B
B
B
The
references
using
the
environment
in
the
case
of
clone
command,
we're
not
doing
that
in
fetch
command,
but
but
I
assume
that
that
was
done
thinking
that
the
first
fetch
the
first
call
is
always
going
to
expand
it.
So
the
second
would
not
need
to
do
that.
So
that
is
why
it
was
it
was
removed.
It
was
not
there
for
the
for
the
decorate,
fetch
command.
A
A
B
And
that's:
okay,
so,
okay,
so
so
we
will
so.
The
next
thing
we
have
here
is
prove
so.
The
issue
I
have
here
is
with
pruning
the
and
the
issue
with
pruning.
Is
that
pruning?
Is
it
it's?
It's
related
to
git
fetch
it's
not
provided
and
get
cloned,
so
so,
when
I'll
be,
although
in
git
clone,
we
are
basically
doing
get
image
plus
plus
get
fetch.
B
The
only
issue
I
had
with
shifting
it
or
adding
it
to
that
api
is
that
clone
doesn't
provide
pruning
and
I
would
be
adding
that
as
an
option
to
to
accommodate
for
to
accommodate
for
this
particular
issue.
So
that's
a
concern.
I
have
that's
that's
a
problem
I
have
while
shifting
it
for
for
the
clean
before
checkout.
I
think
it's
it's
pretty
easy,
but
for
pruning
either
the
branch
or
tag.
B
A
A
A
If
there
are
additional
features,
and-
and
there
are
certainly
examples
of
that
already-
things
like
large
file-
support,
which
might
well
be
better
done
inside
clone
command
than
where
it
is
currently
being
done
so,
but
I
don't
think
that
what
reshab
is
proposing
harms
our
ability
to
add
future
extensions,
he's
just
adding
extensions
in
a
very
reasonable
way
to
clone
command
fran.
Does
that
that
seem
reasonable
to
you.
E
E
A
It's
then
followed
by
another
call
to
fetch
so
fetch
first
and
then
it's
called
by
a
second
call
to
fetch
and
then
the
extensions
that
have
been
added
the
the
the
cleans,
and
so
I
think
what
rishabh
is
suggesting
is
his
goal
is
still
just
to
in
terms
of
get
operations,
remove
the
redundant
fetch
but
continue
persist
in
calling
the
extra
extensions.
The
prune
today
is
implemented
as
a
separate
call
to
get
it.
It
calls
a
get
a
git
prune
or
various
techniques.
B
A
I
cannot
understand
that
yeah,
the
hope,
the
hope
and
again
this
is
there-
are
things
in
in
command
line,
get
that
are
subtleties
that
I
don't
I
don't
expect,
but
I
think
your
logic
is
is
fair,
rishabh,
that
it
probably
won't
affect
performance,
and
we
should
bench
we
should
measure
it
just
to
be
sure.
Maybe.
B
Yeah
we
I
can
create
a
benchmark
to
test
what
fran
is
saying.
I
think
that
would
be
a
good
thing.
I
think
more
practice,
for
benchmarking
is
great,
so
yeah
I'll
do
that
and
yes,
I
think
the
domain
aim
is
to
avoid
it
and
and
do
not
lose
any
kind
of
use
cases
any
possible
use
cases
we
have,
I
think,
do
it
the
most
safest
way
possible,
so
yeah
and
after
this
I
think
the
necessary.
The
most
necessary
thing
is
creating
automated
test
cases.
I
think
the
before
and
after
scenarios.
B
For
so
what
I
was
thinking
was
to,
since
I
have
the
fixed
pr
fixed
branch.
I
have
that
I'll.
I
was
thinking
of
cutting
branches
from
that
particular
branch
for
each
of
the
shifts
I'm
going
to
do
of
the
additions
I'm
going
to
do,
and-
and
I
wanted
to
do
that
and
not
in
a
single
branch.
The
reason
was
that
so
that
we
can
discuss
individually.
B
A
I
I
like
that,
and
I
like
that
very
much
incremental
incremental
sounds
really
good.
I'm
I'm
really
grateful
for
what
you've
discovered,
because
it
was
a
subtlety
that
I
had
completely
missed
in
my
code
review.
I
I
simply
could
not
explain
why
the
the
test
was
failing
with
your
initial
change,
like
what
do
you
mean
all
we
did
was
take
out,
one
fetch.
It
can't
possibly
have
stopped
cleaning,
and
yet
what
your
your
analysis
showed
was.
Oh,
yes,
it
did
stop
cleaning
and
it
stopped
cleaning,
because
the
extension
is
not
registered
in
the
first
call.
A
B
A
So
yeah,
I
would
ask
the
the
other
mentors.
Would
you
be
willing
to
remain
online?
This
feels
like
a
very
effective
session.
I've
got
at
least
another
30
minutes
that
I
could
give
if
other
mentors
are
available,
we'd
be
delighted
to
have
you
stay,
because
it
feels
like
we're
on
a
on
a
very
productive
discussion
topic.
B
Okay,
okay
mark,
so
the
next
thing
I
wanted
to
discuss
was
not
related
to
get
for
this
particular
issue.
It
was
it's
related
to
the
design
document
and
why
I
could
not,
as
of
this
moment,
have
a
consolidated
design
document,
because,
while
in
the
community
bonding,
we
were
discovering
things,
I
I
felt
that
the
document
was
more
of
an
investigation
rather
than
a
consolidated
design,
and
now,
when
we,
when
we
actually
have
a
benchmark
running
in
the
infra
tank,
nci
and
and
and
some
discovery
related
to
this
issue.
B
I
have
a
lot
to
put
in
the
design
document
and
all
the
discoveries
of
the
results
we
have
related
to
the
benchmarks
and
the
profiling,
and
I
just
wanted
to
say
that
I'm
going
to
consolidate
all
of
that
and
release
the
document
within
one
or
two
days,
so
that
people
can
look
at
the
approach.
Mentors
can
look
at
the
approach
I
have
taken
for
the
benchmarks
and
for
the
things
I'm
doing
here,
because
I
I
think
the
benchmarks
have
not
been
the.
We
have
seen
the
results,
but
the
technique.
The
way
I'm
doing
things.
B
That's
that's
something
I
have
to
figure
out
a
way
to
do,
and
I
think
then
another
thing
I
have
to
do
is
testing
the
jmh
visualizer
plugin,
that's
something
I
I
still
I
haven't
tried,
so
I
am
going
to
do
that
this
week
and
I
think,
since
we
have
more
time
so
just
going
to
look
on
my
notes,
what
what
we
can
discuss
here
it
get.
I
think
we
can
discuss.
B
We
can
discuss,
I
ran
a
benchmark
on
get
to
to
show
that
when
we
are
using
double
fetch,
what
is
the
performance
and
when
we
are
not?
What
is
the
performance,
and
so
I
I've
shown
this
result
to
mark
during
my
proposal.
Discussions
not
sure
if
you
remember
it
mark,
but
so
so
how
I
created
this
benchmark.
Let's,
let's
first
discuss
that,
so
I
have
four
tests
and
the
tests.
Basically,
what
they
do
is
the
initial
two
tests.
What
they
do
is
the
first
one
is
just
calling
one
fetch
command.
B
The
second
one
is
also
calling
one
fetch
command,
it's
kind
of
a
baseline
test
to
create
a
reference
point,
the
first
one
with
the
first
one,
I'm
just
fetching
the
master
branch
with
the
second
one.
I
am
fetching
all
the
branches.
So
it's
it's
kind
of
an
a
narrow,
ref
spec
versus
a
wide
rev
spec
comparison.
B
And
after
that,
the
next
two
tests.
I
created
the
benchmarks
they
highlight.
If
we
use
the
fetch
operation
twice,
how
much
time
do
we
gain,
and
that
is
done
with
honoring
refspec
and
when
we
are
honoring
the
ref
spec?
That
means
that,
and
with
that
I
mean
that
the
first
fetch
call
is
going
to
be
narrow
in
this
test
and
the
second
is
going
to
be
wide.
B
B
The
execution
time
is
almost
doubled
in
every
case,
though,
in
cases
of
large
repositories
it
should
have,
it
should
have
considerably
doubled
because,
as
far
as
I
remember
mark
told
me
that
with
small
repositories,
this
is
not
a
concern,
but
in
large
depositories
it's
it's.
It's
it's
much
of
a
big
concern,
bigger
concern,
the
double
fetch
issue,
so
so
this
this
benchmark,
I
created.
While
I
was
writing
a
proposal.
B
So
maybe
there
might
be
some
issue
with
the
way
I've
created
the
benchmarks
that
we're
not
able
to
see
the
differences,
I'm
also
skeptical
about
jvm
optimization.
If,
if
I'm
performing
one
operate,
if
I'm
performing
an
operation
twice
same
operation,
would
the
jvm
optimize
it
put
the
the
when
we
are
measuring
the
second
call?
Would
it
reduce
the
time
for
that
call?
That's.
A
So
to
to
that
question,
I
would
assume
that
jmh
is
doing
its
very
best
to
attempt
to
give
you
preheated
environments
so
that
the
jvm
is
already
as
as
cached
or
as
optimized
as
it's
going
to
be
for
the
first
run
and
therefore
the
first
run
in
the
second
run
would
would
have
comparable
results.
I
think
your
numbers
that
you
had
done
earlier
supported
that
as
well,
that
the
preheat
phase
seemed
to
seem
to
stabilize
seem
to
be
enough
that
the
the
actual
runs
were
quite
stable.
B
A
B
A
So
it
should
have
been,
it
should
have
actually
been.
The
second
phase
should
have
been
a
no-op,
but
but
it's
it's
not
a
no-op
and
the
fact
that
it's
not
a
no-op
is
what
what
has
astonished
a
number
of
our
users
wow.
You
asked
fetch
again
and
I
I
had
to
spend
another
one
minute.
Getting
that
fetch
on
my
big
repository
omkar
go
ahead.
You
say
you
had
a
question.
C
B
Information.
Okay,
so
I
have
I'm
testing
these
benchmarks
for
four
repositories
and
with
each
repository,
the
the
number
of
branches
increase
for
the
first
one.
It's
just
one
branch
for
the
second
one.
As
far
as
I
remember
it's
around
six,
then
it
it's
it's
it's
around.
I
think
10
to
15
for
the
third
one
and
for
the
last
one
I
think
it's
it's
the
most.
I
don't
remember
exactly
the
number
of
branches.
I
I
think
I
can
show
you
the
number
of
branches
for
each
of
the
repository
okay.
So.
C
Differences
that
are
there
in
the
branches
like
one
code
has
hundred
commits
and
second
branches,
like
200
different
commits
so
pulling
that
together
will
cost
get
a
lot
not
just
like
one.
Repo
is
heavy
enough,
but
there
are
no
differences
in
the
branches
that
will
be,
I
think,
lightweight
and
get
might
be
optimizing.
It.
B
B
Yeah
and
and
I
and
when
I
was
creating
the
benchmarks-
that
was
the
initial
assumption
I
so
I
I
took
a
very
structured
repositories
when
I'm
increasing
the
size.
I'm
also
increasing
the
number
of
comments
and
the
number
of
branches
I
actually,
if
I
can
open
the
design
dock.
I
let
me
just
if
I
can
find
the
link
to
the
document.
B
C
A
A
A
C
Proposal
that
that
is
totally
fine,
so
what
I
was
considering
like
he
was
talking,
he
didn't
notice
any
that
much
significant
difference
which
he
had
expected
in
those
graphs
so
for
generating
that
difference
intentionally.
I
was
like
suggesting
this.
That
can
be
one
of
the
factor
to
impact
that
yeah.
A
A
It's
filled
with
150
or
more
independent
branches
that
all
evolve
independently
and
it
is
a
complete.
It
is
a
complete
mess
in
terms
of
its
content
and
it's
intentionally
a
mess.
So
so
so
we
have
a
repository
and
it's
about
40
or
50
megabytes
right
now.
So
it's
it's!
It's
in
the
middle
between
your
it's
between
core
utils
and
cairo
in
in
terms
of
its
current
size,
and
it
just
keeps
growing
okay,
jenkins,
hyphen
bugs
do
not
do
not
do
anything
with
it
right
now.
E
B
Fran
was
talking
about
in
the
performance
and
I
think,
while
I'm
doing
that,
so
these
are
the
for
the
next
week.
I
think
these
three
two
tasks
I
have
in
terms
of
coding,
the
third
I
can
possibly
possibly
have
is
of
researching
how
I
can
implement
the
the
get
the
opt-in
feature
for
the
gate
performance
for
the
performance.
Benchmarking
improvements,
you're
going
to
do
so,
yeah
any
concerns
related
to
the
tasks
I
have
or.
B
B
A
A
Would
love
it
if
you
don't
mind
giving
10
or
15
minutes
or
a
five
or
ten
minute
summary
of
hey
here's,
what
we've
learned
since
the
last
time?
I
think
it's
been
about
four
weeks
since
you
last
talked
at
the
at
the
platform
sig,
and
so
it
would
be
a
great
excuse
to
share
your
results
up
to
that
point,
to
highlight
progress
to
indicate
problems,
etcetera.
A
It
happens
each
thursday
at
6
a.m.
Mountain
time
so
justin,
it's
it's
almost
unbearably
early
for
you.
It's
5
a.m,
your
local
time-
and
I
I'm
sorry
for
that.
But
that's
that's
when
the
contributors
to
that
particular
special
interest
group
could
meet
so
we
do
it
very
early
so
that
we
fit
with
the
european
schedule
and
with
one
of
our
colleagues
from
broadcom
who
really
likes
to
get
up
early
in
the
morning,
even
though
he
lives
in
phoenix
arizona.