DVCS vs. Subversion brittleness (was Re: Moving to D)

[Michel Fortin]

On 2011-02-11 08:05:27 -0500, Bruno Medeiros 
<brunodomedeiros+spam at com.gmail> said:

> On 09/02/2011 14:27, Michel Fortin wrote:
>> On 2011-02-09 07:49:31 -0500, Bruno Medeiros
>> <brunodomedeiros+spam at com.gmail> said:
>> 
>>> I was about to say "Cool!", but then I checked the doc on that link
>>> and it says:
>>> "A shallow repository has a number of limitations (you cannot clone or
>>> fetch from it, nor push from nor into it), but is adequate if you are
>>> only interested in the recent history of a large project with a long
>>> history, and would want to send in fixes as patches. "
>>> So it's actually not good for what I meant, since it is barely usable
>>> (you cannot push from it). :(
>> 
>> Actually, pushing from a shallow repository can work, but if your
>> history is not deep enough it will be a problem when git tries determine
>> the common ancestor. Be sure to have enough depth so that your history
>> contains the common ancestor of all the branches you might want to
>> merge, and also make sure the remote repository won't rewrite history
>> beyond that point and you should be safe. At least, that's what I
>> understand from:
>> <http://git.661346.n2.nabble.com/pushing-from-a-shallow-repo-allowed-td2332252.html>

Interesting. 
>> 
> But it still feels very much like a second-class functionality, not 
> something they really have in mind to support well, at least not yet.
> 
> Ideally, if one wants to do push but the ancestor history is 
> incomplete, the VCS would download from the central repository whatever 
> revision/changeset information was missing.

Actually, there's no "central" repository in Git. But I agree with your 
idea in general: one of the remotes could be designated as being a 
source to look for when encountering a missing object, probably the one 
from which you shallowly cloned from. All we need is someone to 
implement that.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/