On 2011-02-11 08:05:27 -0500, Bruno Medeiros
<brunodomedeiros+spam@com.gmail> said:
On 09/02/2011 14:27, Michel Fortin wrote:
On 2011-02-09 07:49:31 -0500, Bruno Medeiros
<brunodomedeiros+spam@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.for...@michelf.com
http://michelf.com/
