Re: [boost] [Git] Documentation update

Subject: Re: [boost] [Git] Documentation update
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2013-02-14 00:30:10

On Wed, Feb 13, 2013 at 11:18 AM, Dave Abrahams <dave_at_[hidden]> 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_at_[hidden]>
> 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_at_[hidden]>
> >> wrote:
> >> >> On Tue, Feb 12, 2013 at 8:25 AM, Beman Dawes <bdawes_at_[hidden]> 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