On Thu, May 2, 2013 at 1:24 PM, W. Trevor King wrote:
> On Thu, May 02, 2013 at 07:05:11PM +0100, Aron Ahmadia wrote:
> > *Even forcing people to do "git submodule init && git
> > submodule update" adds friction.*
> > *
> > *
> > Tell them to do:
> > git clone --recursive ipython/ipython # this does the submodule
> > init/update bits for you
> Brian raises a good point. When I start working on a new project, I
> usually clone upstream. If I actually write a useful PR, I fork on
> GitHub (via `hub fork`). With this approach, the relative submodules
> work fine.
This is how I work as well, and why I was persuaded by your argument until
I heard from Brian.
> If you *start* your development with a fork on GitHub and subsequent
> local clone of your fork, you're going to run into problems with
> relative submodule URLs. If we already have IPythonistas that have
> tripped over this problem, hard coded URLs may be the way to go.
> > Submodules add an unfriendly level of complexity, but it turns out
> > that version control is a hard problem :/
> I think it's mostly that submodules were designed for a distribution
> management perspective, so pulling in lots of optional submodules with
> loose bindings between them is easy. Making submodularization
> transparent (strong bindings) is more difficult, although there's been
> a lot of work upstream over the past few months to make submodules
> more of a first class citizen:
> git$ git log --all --oneline --grep submodule --since=2013-02-01 | wc
Thanks for your help guys, we are a bit new to this stuff.
> This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
> For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
> IPython-dev mailing list
> [email protected]