[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-scm-interest
Subject:    Re: [Kde-scm-interest] [Kde-games-devel] Data files and the Git move
From:       Oswald Buddenhagen <ossi () kde ! org>
Date:       2011-09-06 15:06:25
Message-ID: 20110906150624.GA8961 () troll08 ! nokia ! trolltech ! de
[Download RAW message or body]

On Mon, Sep 05, 2011 at 11:37:33PM +0200, Thiago Macieira wrote:
> On Monday, 5 de September de 2011 17:06:42 Oswald Buddenhagen wrote:
> > > I understand why you can never update it (fetch into it), since the remote
> > > may conclude that it doesn't need to send some objects.
> > 
> > because it might assume that objects which should be reachable from the
> > old heads need not be transferred? 
> 
> Yes.
> 
> > changing this sounds like a simple protocol extension to me ...
> 
> Adding the extension might be trivial. Collecting the information to send and 
> making use of it might not be.
> 
> The fetcher side needs to scan the entire commit history and find which commits 
> are missing. Right now, it only needs to send the list of branch heads.
>
missing commits are trivial, because they are unique within the graph, so
just sending the "have" sha1s as cut-off points is sufficient.
it gets more interesting for trees and blobs, as previously reachable
objects might not be actually in the clone. but that's actually easy,
too - objects referenced only from below the cut-off points are assumed
to be missing.

fwiw, what would be *really* cool would be on-demand fetching, so if you
do a deep history search in a directory, you automatically fetch the
commits, trees and text blobs for the searched scope, but nothing else.
that amounts to a lot of cut-off points to send to the remote, though.
_______________________________________________
Kde-scm-interest mailing list
Kde-scm-interest@kde.org
https://mail.kde.org/mailman/listinfo/kde-scm-interest
[prev in list] [next in list] [prev in thread] [next in thread]