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. Thanks, Patrick _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
