On Fri, Aug 07, 2009 at 08:39:16PM -0700, Mark Polesky wrote:
Patrick McCarty wrote:
> I've just tested git's shallow cloning feature. It's pretty
> neat.
> :-)
>
> From what I can see, shallow clones would be okay for *casual*
> contributors that are only sending patches based on the tip of
> master.
>
> However, since git history is limited to the depth of the
> clone, then
> shallow clones would not permit a developer to revert a commit
> from,
> say, three weeks ago.
>
> In other words, I think both the "git clone" and "git
> clone --depth"
> methods should be included in the CG.
To me, it seems that a developer should be able to just stick to
shallow clones for everyday use. I assume that one could simply
increase the depth of the clone when needed. Is that true? I've
never
needed to revert a three-week old commit, but if I needed to, I
figure I would just do another clone with a greater depth.
Does it work that way?
I suppose that sounds reasonable, but if you "reclone" a
repository
two or three times, each time with greater depth, then you'll
probably
be using more bandwidth than if you had just downloaded the entire
repo initially (with "git clone").
Really, it all depends on how developers use git history.
Personally, I browse git history on the command line quite often
when
working with LilyPond.
A while back, I needed to find a change made to a certain file
several
years ago (I don't remember which file). To exacerbate the
problem,
the file had been renamed once or twice. But git makes this easy:
$ git log -p --follow file.scm
Then I found the commit I was looking for very quickly.
But maybe others don't use git history quite as extensively. I
don't
know.