►
From YouTube: 2020 07 31 GSoC Git Plugin Performance Project
Description
Jenkins Google Summer of Code project for Git plugin performance improvement July 31, 2020.
A
So
I
think
we
should
right
now
start
with
what
we
have
to
do
with
the
image
it.
The
most
thing
we
have
in
priority
and
that's
the
get
to
choose
it,
and
so
the
status
with
get
to
chooser
is
that
it's
the
business
logic
is
mostly
done.
I
think
fran
has
reviewed
the
latest
comments
and,
apart
from
one
or
two
optimizations,
he
was
saying
that
we
could
do
you're
saying
that
functionally
the
pr
looks.
A
Okay
and
I
have
added
six
test
cases
automated
test
cases
where
I
the
cases
they
range
from
using
existing
cache.
If
we
have
cache
it
calculates
the
size,
then
we
have
cases
where
we
have
one
extension,
two
extensions
or
if
an
extension
is
throwing
an
exception.
So
I
have
some
cases.
I've
covered
some
of
the
basic
cases
for
the
class.
I
I
I'm
sure
that
we
need
more
cases
there.
Now
the
one
of
the
one
of
the
major
blocker.
A
I
was
thinking
with
that
pr
for
merging
it
was
that
it
does
not
stop
it.
Doesn't
it
it
recommends
jake
it
when
it
should
not.
So
we're
not.
We
were
not
looking
for
lfs,
checkout
and
spark
checkout
and
for
those
extensions
we
need
to,
we
need
not
to
recommend
jkid.
So
for
that
I've
come
up
with
the
solution.
A
A
So
what
we
can
do
is
that
we
can
add
another
responsibility,
give
another
responsibility
to
the
get
tool
chooser
that
it
it
asks
the.
So
what
we
do
is
just
a
second.
I
have
the
git
scm
extension
class.
I
need
to
open
it,
so
we
decorate
our
clone
command,
checkout
commands
and
another
many
other
operations
we
need
for
whom
we
need
to
modify
the
behavior.
A
So
we
could
add
another
decoration
tool
here
where
we
decorate
the
tool,
the
git
tool.
So
what
we
do
is
that,
while
we're
we're
in
the
process
of
recommending
the
git
tool,
we
could
search
for
the
extensions
available,
get
sem
extensions
in
the
project
and
then,
since
this
will
be
implemented
by
two
extensions
and
that
would
be
lfs
pull
and
the
spark
sparse
checkout
I
could
ask
for
so.
A
If,
for
any
case
in
the
future,
I'm
not
sure
if
git
has,
of
course
get
doesn't
there's
no
functionality
which
git
would
not
work
because
git
is
providing
the
functionalities
it
would
have
to
clone
them,
but
still
I've
kept
it
general.
If,
for
some
any
case,
gate
is
a
git,
has
it's
it's
it's
a
case
where
git
should
not
be
recommended?
A
A
That
would
be
a
problem.
What,
if
someone
says
jet
is
false?
It's
not
supported,
but
some
other
for
the
other
extension
it
is,
it
is
supported
and
if
it's
implemented
there,
that
would
be
a
problem.
If
it's
not.
Ideally,
it
should
not
be
implemented
where
the
extension
doesn't
have
to
worry
about
support,
supporting
and
implementation
or
not.
But
I
guess
that
could
be
a
concern.
B
I'm
trying
to
comprehend
here
so
the
the
responsibility
to
know
by
the
way,
as
as
a
word
of
warning,
there
are
more
get
sem
extensions
that
are
not
implemented
in
jgit
than
just
the
two
that
are
listed,
so
it
it
there
are
there,
it's
it's
sparse,
checkout
is
not
implemented.
There
are
several
others,
so
so
it
this
is,
it's
not
just
a
case
of
two.
There
will
be
multiple
there
are.
There
are
more
than
that,
okay,
and
so
I
think
that
what
you
were
proposing
is
that
the
responsibility
to
answer
the
question.
B
B
A
A
I
was
looking
at
j
gets
implementation
and
for
j
this
is
null
or
the
point
is
that
we
we
at
this
extension
we
could
have
the
information
where
we
know
that
j
j
git
can
be
supported
by
this
extension
or
not,
but
at
the
level
of
get
tool
chooser
it
would.
We
would
have
to
do
a
lot
of
work
to
understand.
If
that
extension,
we
would
have
to
hard
code
some
kind
of
a
rule.
A
A
At
that
point,
I
think
we've
made
the
decision
if
at
jet
we
basically
just
throw
an
exception.
I
I
was
seeing
the
code.
We
throw
exceptions
when
we,
when
we
see
variables
like
lfs,
remote
or
sparse
checkout
path,
so
I
think
the
decision
to
delegate
the
responsibility
to
the
exchange
ask
the
extension.
If
it's
supporting
or
not
is,
is,
I
think,
logical
in
this
case.
Instead
of
letting
get
tool
chooser
getting
that
responsibility.
B
Okay,
so
so
git
tool,
chooser
then
asks
or-
or
it
has
two
alternatives.
I
guess
three
alternatives
right
now.
It
could
choose
j,
get
api
input,
it
could
choose
jet
api
apache,
impul
or
it
could
choose
cli
get
api
info
right.
So
those
are
the
those
are
its
three
choices
and
and
a
specific
job
has
a
collection
of
of
get
sem
extensions
associated
with
that
job.
B
B
He
or
could
we
give
the
cli,
get
api
input
and
the
jgit
api
and
pull
the
the
set
of
extensions
that
are
being
requested
and
ask
them?
Do
you
veto
you're
being
offered
as
one
of
the
get
tool
choices,
and
I
I'm
so
back
to
I'm
not
sure
that
I'm
I'm
comprehending
where
you're
envisioning,
you
would
put
the
the
the
knowledge
of
okay.
A
I
think
I
should
explain
this
a
little
better,
so
let's
just
go
to
get
scm
first.
So
when
we're
looking
at
git
scm,
this
is
the
function
we
use
to
create
a
client.
This
is
called
when
we're
checking
out
a
repository
so
for
the
demo.
I
tried
this
this
right
now
we're
not.
We
haven't
added
anything
where
we
would
recommend
jigget.
A
We
would
not
recommend
jacket
if
we
have
lfs
source
pass.
So
here
what
we
are
seeing
is
that
I
get
the
I'm
not,
although
technically
this
is
not
being
used
now,
so
usually
we
get
the
exa
the
executable
from
a
function
and
then
so
what
I'm
doing
is
I'm
calling
my
I'm
calling
my
estimator
one?
Second,
this
is
yeah,
so
I'm
calling
the
get
to
chooser
here
with
the
url.
A
So
here
I
just
put
the
recommendation
using
get
xe
exe
and
then
the
client
is
created,
and
so
I
I
I
think
I
would.
I
would
assume
that
once
we've
done
that
we
are
covering
all
the
cases
for
the
git
scm
class
anywhere,
a
client
would
be
created
would
be
created
with
this
recommendation
now,
if
we
are
talking
about
checking,
if,
if
the
implementation
is
supported
by
the
extension
or
not,
we
would
we
would,
we
would
have
to
do
this,
we
would
do.
We
would
have
to
do
that
at
this
level.
A
A
A
Can
we
just
not
say
that?
Okay,
this
is
going
to
be
false
for
jigget
always
and
just
return
that
to
return
that
to
get
to
choose
and
as
get
to
chooser,
I
would
be
sitting
and
looking
for
looking
at
the
extensions
and
if
I
receive
a
false
from
anywhere,
I
would
block
the
recommendation
and
not
give
anything.
B
Yeah-
and
I
think
I
think
I
think
that
is
that
is
that,
would
if
you
go
back
to
the
to
the
function,
you
had
there
just
a
minute
ago,
the
the
one
that
was
iterating
extensions
yeah,
so
on
line
868,
where
it
it
iterates
over
the
extensions
to
take
your
your
idea.
I
was
thinking
if
estimator
dot
get
tool,
dot,
estimator
dot,
get
get
tool
took
the
the
argument,
which
is
the
list
of
extensions.
B
It
could
conceivably
then
know
everything
it
needs
to
about
hey.
I
know
these
things.
Admittedly,
that's
not
asking
jay
git
itself
to
tell
us
is
this:
is
this
implemented,
but
it
would
give
us
a
quick
way
to
say
inside
the
estimator
if
the,
if
the
request,
if
the
extension
for
lfs
is
included,
veto
any
use
of
jgit,
if
the
request
for
sparse
checkout
is
there
veto
any
use
of
jgit,
it
must
always
use
cli
git.
A
B
So
so
in,
in
that
case,
estimator.getgettool
would
take
one
more
argument,
the
list
of
extensions
and
it
would
just
have
a
hard-coded
list
inside
now.
That's
that's
not
my
java
coding
friends
who
actually
are
very
good
at
java
coding,
would
probably
mock
me
terribly.
So
I'm
I've
I've
just
described
something
to
you.
That
looks
an
awful
lot
like
what
a
c
programmer
would
do,
and
I
I
apologize
for
doing
that
to
you.
That's
that's
really
bad
mentoring,
but
but
it's
that
kind
of
thing.
B
C
No,
I
was
just
gonna
say
I
think
that
seems
like
a
good
way
of
of
getting
this
in
with,
because
I
think
you're
proposing
to
put
this
in
with
this
pr.
So
I
think
that's
also
a
good
way
to
get
this
in
the
pr
to
make
sure
that
this
works
properly
without
going
too
far
architecturally
like
into
the
you
know
the
perfect
solution.
I
guess,
but
maybe
that's
not
that
far
away.
I
like
the
suggestion
of
using
the
estimator
and
passing
that
in
somehow
so.
B
Yeah,
would
you
object
rishabh
to
trying
to
pass
in
the
list
of
extensions
to
the
get
to
to
get
to
the
estimator's,
get
get
tool
method
and
let
it
use
a
hard-coded
list
initially
and
then,
if
we
can
find
a
better,
more
object-oriented
way
to
do
it?
We
do
that,
but
for
me,
passing
in
a
hard
passing
it
in
and
having
it
checked
against
a
known
list
of
problems
and
extensions
seems
simple
enough
for
me
to
understand
it.
A
But
I
think
we
we
can
have
something
which
to
get
which
we
do
here.
So
what
we
can
do
is
that
the
extensions
are
implementing
the
get
sem
extension
and
if
we
have
a
method
there,
which
a
contract
which
says
decorate
the
git
tool,
which
basically
means
that
I
encode
the
information
at
that
level.
The
extension
encodes
that
it
is
the
responsibility
of
the
extension
to
implement
that
method,
which
is
to
decorate
the
git
tool
and
then
say
that
okay,
I'm
going
to
tell
you
that
j
for
j
git.
A
A
It
takes
a
map
which
links
the
implementation
to
its
support.
So
if
the
extension
tells
me
that
maybe
we
can,
we
don't
need
to
use
a
map,
but
if
the
extension
tells
me
that
for
a
string
j
get
false,
it's
false,
I
would
just
I
would
not
my
implementation.
So
what
I
do
is
that
I
check
if
I
am
recommending
it
and
if
the
extension
is
telling
me
that
jj
is
false,
I
would
recommend
nothing
or
recommend
git.
That's.
A
I
didn't
think
about
what
I
would
recommend
after
that
part
part,
because
then
we
would
again
have
to
look
if,
if
I
recommend
git
instead
of
jkt,
I
would
have
to
look.
I
would
have
to
resolve
it
get
if
git
is
present
in
the
node
or
not
in
the
machine
or
not,
but
we
we
could
decide
that
after
that
point.
But
at
till
this
point
instead
of
taking
a
list
and
then
hard
coding
that
okay
for
git
lfs
pool
or
for
sparse
checkout
we're
not,
we
will
just
not
recommend
jacket.
A
We
could
create
a
method
which
would
it's
basically
doing
the
same
thing.
I
think,
but
I
I
was
just
following
what
the
git
plug
what
I
have
seen
in
the
git
plugin.
How
do
we
modify
the
behavior
of
clients
using
the
extensions?
That
is
what
I've
seen
so
I
I
guess
I
should
first
submit
this
as
a
commit,
and
then
we
could
have
a
better
discussion
over
this,
because
I
think
me
saying
this
would
not
100
explain
it
clearly.
B
A
C
Yeah
people
might
scream
at
me,
though
too,
but
I
guess
I'm
I'm
just
wondering
if
maybe
the
extension
should
know
more
about
implementations,
it
can't
use
and
then
the
get
tool
chooser
uses
that
information,
so
that
the
extensions
don't
have
to
know
anything
about
the
get
tool
chooser
and
the
git
tool.
Chooser
already
has
the
responsibility
of
choosing
which,
which
one
you're
going
to
go
going
through
all
the
lists
and
then
finding
the
optimal
one.
And
then,
if
that's
not
supported,
then
you
can't
pick
that
one.
A
So
this
is
what
I
would
suggest
what
I
had
in
my
mind
so
so
now,
right
now,
the
git
lfs
pull,
would
add
this
method,
overwrite
the
method,
decorate
tool
and
would
put
some
logic
and
tell
me:
okay.
Is
it
supported
or
not
with
the
current
git
tool,
chooser
object
and
then
return
the
object
again
and
then
I
can
use
that
updated
object
and
get
the
get
tool
and
recommend
the.
A
C
C
A
C
A
C
C
C
C
A
B
B
B
B
B
A
A
A
This
is
x
the
extension
but
to
get
lfs
pull.
I
I
assume
that
I
assumed
that
it
would
have
the
information
to
know
that
it
is.
It
is
not
supporting
jj,
so
it
would.
It
would
tell
so
this
way.
I
figured
out
this
way
to
tell
chooser
that
okay,
I
cannot
support
jacket
and
just
know
that
and
then
the
chooser
can
decide
to
recommend
either
git
or
no
nothing.
B
I
see
okay,
thank
you
for
the
clarity.
I
think
I
think
I've
I'm
starting
to
comprehend
your
vision.
It
is
that
the
the
the
git
lfs
pull
extensions,
decorate
tool
method
is
called
and
it
relies
on
git
lfs
pull
to
call
the
chooser
that
is
passed
in
and
tell
it
supported
or
not.
So
it's
it's
passing
in
hey
here's
a
thing
I
get
tool
chooser
now
extension.
B
Your
responsibility
is
to
annotate
this
thing
supported
or
not
supported,
and
if
it's
not
supported
the
get
tool,
chooser
then
says
I
will
ignore
this
as
an
alternative,
because
it
doesn't
support
this
extension.
That's
been
requested.
Okay
thanks,
forgive
my
forgive
my
being
so
slow
to
catch
on.
Thank
you
very
much.
C
C
So
I
don't
think
anything
else
like
forgive
the
question,
but
as
not
a
not
a
corrugat
plug-in
maintainer.
That's
where
my
question
is
coming
from.
I
I
think
this
is
a
new
thing
that
the
plug-in
can
do
in
terms
of
who
knows
what
the
capabilities
are
like
in
terms
of
who
knows
what
git
tool
has
what
capabilities
right.
B
B
It's
embarrassing
in
how
many
different
ways
it's
hidden,
it's,
let's
see,
throw
an
exception
or
just
give
a
message
or
don't
do
anything
just
silently
ignore
it
and
those
are
all
completely
inconsistent
and,
of
course,
because
of
the
history
of
the
plug-in.
We
have
to
retain
them
as
completely
inconsistent
in
their
behavior,
because
otherwise
somebody
will
be
broken.
Who
depended
on
that
bizarre
behavior.
A
B
B
A
That
is
something
else
so
forget,
lfs
poll.
I
know
that
it's
an
x,
it
extends
they
get
a
cm
extension
and
then
once
we
have
to
use
I,
what
I've
seen
in
the
code
is
that
this
variable
called
the
lfs
remote,
it's
included
in
both
jet
and
the
clicket
implementation,
but
in
the
case
of
jk
implementation,
I
think
it
it
checks.
If
it's
not
null,
then
it
throws
an
exception.
It.
It
checks.
The
this
was
an
exception.
B
So
so
to
justin's
point
get
lfs
pull
is
the
extension,
but
it's
actually
not
doing
the
implementation.
It's
relying
on
jet
api
impul
or
on
cli
get
api
to
do
the
implementation.
So
so
this
thing
get
lfs
pull,
doesn't
actually
know
that
jgit
doesn't
implement
it.
So
all
the
knowledge
about
what's
implemented
or
what
isn't
is
inside
jkd,
api,
impul
class
or
cli
get
api
input
class.
A
Yes,
it
would,
this
extension
would
configure
the
lfs
remote
variable
in
none
other
than
this
it.
It
doesn't
care
about
the
implementations,
as
mark
has
said
only
once
we
reach
to
the
point
where
we
are
implementing
the
particular
when
you're
checking
out
the
repository,
and
if
you
have
to
check
lfs
remote
in
terms
of
jkt,
it
would
throw
an
exception,
get
what
cli
get
what
do
it
perform,
so
it
does.
B
Doesn't
that
hint
that
decorate
tool,
what
you
may
want
to
consider
is
should,
instead
of
asking
the
extension,
are
you
supported?
Should
we
ask
the
implementation,
cli
get
or
jay
get
api
impul,
because
that's
where
the
knowledge
is
right
now
it's
embarrassing
that
the
knowledge
is
there
right.
It's
it's
awkward
and
flawed
that
the
knowledge
is
there
instead
of
in
the
extension,
but
that's
where
the
knowledge
is
so
so
maybe
we
should
ask
the
implementation
rather
than
the
extension
are
you
are?
Are
you
a
val?
C
C
B
Could
be,
but
it
is,
it
is
that's
a
that's
a
user
description
at
the
and
and
then
that's
even
more
complicated,
that's
something
we
haven't
touched
on
at
all.
It
is
allowed
to
have
multiple
input.
Multiple
multiple
git
tools,
but
the
code
right
now
makes
the
decisions
about
capabilities
at
run
time
very,
very
late.
It
asks
the
specific
get
implementation.
What's
your
version
and
then
senses
based
on
that
version.
Number.
C
Yeah
I
mean
I
actually
kind
of
like
your
suggestion
of
having
it
with
the
tool,
because
the
tool
should
know
what
it
what
it
supports
right,
like
I'm,
not
suggesting
that
we
get
this
version
level
thing.
But
taking
this
even
further,
you
could
say
like
get.
1.85
doesn't
support
like
this
new
thing
that
you
want
and
get
2.2,
and
then
you
won't
pick
that
one
you
would
pick
2.2
if
that's
available
or
you'd
say
I
don't
have
anything
that
supports
this
right
and
and
sorry.
The.
B
Use
case
you're
describing
is
very,
very
real.
Centos
7,
as
the
is
the
poster
child
fully
supported,
production
operating
system
used
all
over
the
world
with
git,
1.8
and
yeah.
Yes,
all
sorts
of
people
use
it
right.
I
mean,
and
but
latest
debian
release
get
2.20
latest
windows
version
2.28,
you
know
so
so,
and
yeah
we've
got
a
wide
range
of
version
numbers
and
I
hope
in
some
future
day
to
drop
support
completely
forget
1.8,
but
you
know
that
that's
not
gonna
happen
until
centos.
Seven
is
dead
and
long
after
that.
B
B
C
B
And
I'm
not
sure
you
want
to
mess
with
that,
but
that's
up
to
you.
Yes,
there
are
several
right
because
there
was
a
good
api
that
was
implemented
many
years
ago
and
it
provides
one
thing
and
it's
all
deprecated
but
critically
important,
and
so
yes,
there
are
interfaces.
No,
I
don't
know
if
that
will
help
in
this
case.