Re: Performance issue: initial git clone causes massive repack

4 messages, 3 authors, 2016-06-15 · open the first message on its own page

Re: Performance issue: initial git clone causes massive repack

From: Matthieu Moy <hidden>
Date: 2016-06-15 22:46:33

Nicolas Pitre [off-list ref] writes:
If for example you have a single pack because your repo is already fully 
packed, then the "packing operation" involved during a clone should 
merely copy the existing pack over with no further attempt at delta 
compression.
There's still the question if your repository has too many objects
(for example, a branch that you deleted without garbage-collecting
it). Then, sending the whole pack sends data that one may have
considered as "secret".

To me, this is a non-issue (if the content of these objects are
secret, then why are they here at all on a public server?), but I
think there were discussions here about it (can't find the right
keywords to dig the archives though), and other people may think
differently.

Jeff King's answer in [off-list ref]
tackles this problem too.

-- 
Matthieu

Re: Performance issue: initial git clone causes massive repack

From: Nicolas Pitre <hidden>
Date: 2016-06-15 22:46:33

On Mon, 6 Apr 2009, Matthieu Moy wrote:
Nicolas Pitre [off-list ref] writes:
quoted
If for example you have a single pack because your repo is already fully 
packed, then the "packing operation" involved during a clone should 
merely copy the existing pack over with no further attempt at delta 
compression.
There's still the question if your repository has too many objects
(for example, a branch that you deleted without garbage-collecting
it). Then, sending the whole pack sends data that one may have
considered as "secret".
I said "merely copy", which is not a straight copy.  In this case, only 
the relevant objects from the existing pack will be copied into the 
streamed pack, and objects from the unused branch will be left behind.  
In that case, deltas which base object is left behind will automatically 
be considered for alternative delta matching of course, but that is 
normally a relatively small set of objects.  And if that set gets really 
big, that means that an even bigger set of objects was left behind, 
making the actual repacking smaller in scope.
To me, this is a non-issue (if the content of these objects are
secret, then why are they here at all on a public server?), but I
think there were discussions here about it (can't find the right
keywords to dig the archives though), and other people may think
differently.
Guess who was involved in that discussion...

I may allow you to pull certain branches directly from my own PC through 
the git native protocol.  That doesn't mean you have direct access to 
the whole of any of the packs I have on my disk.


Nicolas

Re: Performance issue: initial git clone causes massive repack

From: Robin H. Johnson <hidden>
Date: 2016-06-15 22:46:34

I haven't read all this morning submissions to the thread yet, but I
wanted to make two posts before I leave on a trip (in ~20 minutes), and
I'll be back late on Thursday.

On Mon, Apr 06, 2009 at 09:29:04AM -0400, Nicolas Pitre wrote:
quoted
To me, this is a non-issue (if the content of these objects are
secret, then why are they here at all on a public server?), but I
think there were discussions here about it (can't find the right
keywords to dig the archives though), and other people may think
differently.
Guess who was involved in that discussion...
I may allow you to pull certain branches directly from my own PC through 
the git native protocol.  That doesn't mean you have direct access to 
the whole of any of the packs I have on my disk.
If the native rsync protocol is allowed to the repo, then that argument
is moot.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Re: Performance issue: initial git clone causes massive repack

From: Nicolas Pitre <hidden>
Date: 2016-06-15 22:46:34

On Mon, 6 Apr 2009, Robin H. Johnson wrote:
I haven't read all this morning submissions to the thread yet, but I
wanted to make two posts before I leave on a trip (in ~20 minutes), and
I'll be back late on Thursday.

On Mon, Apr 06, 2009 at 09:29:04AM -0400, Nicolas Pitre wrote:
quoted
quoted
To me, this is a non-issue (if the content of these objects are
secret, then why are they here at all on a public server?), but I
think there were discussions here about it (can't find the right
keywords to dig the archives though), and other people may think
differently.
Guess who was involved in that discussion...
I may allow you to pull certain branches directly from my own PC through 
the git native protocol.  That doesn't mean you have direct access to 
the whole of any of the packs I have on my disk.
If the native rsync protocol is allowed to the repo, then that argument
is moot.
The rsync protocol is _not_ the native git protocol.  And I personally 
don't encourage its usage either, except as a _temporary_ workaround for 
unresolved issues.  You will never see this protocol available from any 
git server I maintain.


Nicolas
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help