On Wed, Feb 13, 2013 at 11:18 AM, Dave Abrahams <dave@boostpro.com> wrote:
on Wed Feb 13 2013, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
On Tue, Feb 12, 2013 at 10:07 AM, Dave Abrahams <dave@boostpro.com> wrote:
on Tue Feb 12 2013, Beman Dawes <bdawes-AT-acm.org> wrote:
On Tue, Feb 12, 2013 at 10:37 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Tue, Feb 12, 2013 at 8:25 AM, Beman Dawes <bdawes@acm.org> wrote: ...
I must be missing something. Why not just work through the python subprocess interface? As Dave points out, the git interaction is really simple, so isn't
the
subprocess approach sufficient?
It's not sufficient.. As I can't rewrite the subrepo references to use the HTTPS protocol instead of the GIT protocol (which is how they are currently encoded)
We can fix that on our end of course.
Sure.. But this is one of those cases where the git design is less than ideal (not the svn does any better in this regard). In an ideal world the subrepo references would have a list of alternatives for protocols and client code could pick the correct one to match the protocol the client prefers. Which is a long way of saying it's going to be less hassles in the long run if I adjust the references to suit the client needs manually since I know the possible alternatives as we are only dealing with github.
Sure you can; Just git clone non-recursively and then edit the
.gitmodules file.
But then I have even more code that is managing a file I don't really want to manage.
As opposed to now where I have about 150 lines of easy to read portable python code that does all the subrepo stuff while limiting the clone/pull/checkout to only the tested branch. And hence at least saving some disk space.
If you're trying to save disk, you could try using a shallow clone(?)
That would be the first thing I tried almost two months ago with the git CLI. And it turns out to not be currently possible as fetching subrepos recursively ignores the shallow clone for the subrepos. I subsequently spent from that time up to a short time ago trying to do a shallow clone with dulwich without "intellectual" success (i.e. I don't understand enough of the protocol and API to do it). And gave up on that for now. So it's now not space efficient.. But at least it works. I'll see about finding out a way to do the shallow clone in the future. NOTE.. I'm referring to calendar time there.. Actual effort time is rather small. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo