Re: dangling commits

From: Nick Williams <njw@jarb.freeserve.co.uk>
Date: Jan 15, 2006, 21:37 UTC
Message-ID: <dqedel$d0q$1@sea.gmane.org>
In-Reply-To: <43CAB6ED.3010703@op5.se>

Andreas Ericsson wrote:

Show 30 quoted lines

> Nick Williams wrote:
> 
>> Hi, after cloning the git repo with
>>
>> cg-clone http://www.kernel.org/pub/scm/git/git.git git
>>
>> and then doing
>>
>> git-fsck-objects --full
>>
>> I get the following
>>
>> dangling commit 42db15448ea3c21ae458d5ea873157449042c07c
>> dangling commit 4d04a4022e7f9f3ada3a64e2010ce65e1fcc5c64
>> dangling commit a773f5bda1835d739ee7209589e137ddd7199142
>> dangling commit ceb90a511add3b362f1384aa6ea35370d12db315
>>
>> However if I do cg-clone git://git.kernel.org/pub/scm/git/git.git
>> there's no output from git-fsck --full
>>
>> git version = 1.1.GIT
>> cogito version = cogito-0.17pre.GIT
>>
>> did I do something wrong (again)?
>>
> 
> Nopes. One clones over http, so you'll get all objects in the object 
> database. The other clones over the far more clever git protocol which 
> calculates which objects you need. Obviously you don't need dangling 
> commits (and their related blobs), so there will be no such items.

OK, that makes sense - thanks for the explanation.

Show 5 quoted lines

> 
> That there are on kernel.org at all is because Junio does rebases of the 
> pu branch and then pushes them out, which means that the objects from 
> the last rebase of that branch are left dangling.
>

So, is there any advantage of using http? Seems like git:// makes more sense.