<div dir="ltr"><div><div><div><div><div>Stefan,<br><br></div>My biggest issue with this is that branching is not a cell-level phenomenon.<br><br></div>The example in my video/screenshots have branches that each only contain one cell, but that was largely for simplicity and the ability to fit it all on screen for illustration purposes.<br>
<br>In most cases a branch in the sense that I am envisioning them will actually be a sequence of cells which together make up a particular alternative (strategy|algorithm|implementation|*). They need to be tracked as a group and operated on as a group. It is explicitly invalid (though not prevented currently in my PoC) when given 2 branches with 3 cells each, to run the first cell in branch one, then the second cell from branch 2, then the third from branch one again. That doesn't constitute a valid path through the document.<br>
<br></div>Having the branches stored externally (which is what putting them in git amounts to) also seems like it would gut our ability to easily reason about the structure of and navigate through the document. Under this model navigating between paths through the analysis actually changes content of the notebook itself. Also given four distinct sets of branches, how does that translate into the actual document structure? Even attempting to do so requires scraping data from the git repo, and its not clear how straightforward things would be even in that case.<br>
<br></div>Nesting branches (alternative analysis strategies, one branch of which contains alternative choices for model specification, for example) seem tough to do as well in a way that we can easily extract and reason about when we want to render or navigate the notebook.<br>
<br></div><div>~G<br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 10, 2013 at 11:40 AM, Stéfan van der Walt <span dir="ltr"><<a href="mailto:stefan@sun.ac.za" target="_blank">stefan@sun.ac.za</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, Jul 10, 2013 at 8:25 PM, Gabriel Becker <<a href="mailto:gmbecker@ucdavis.edu">gmbecker@ucdavis.edu</a>> wrote:<br>

><br>
> That having been said, there is a far cry between git being the place that the devs think notebooks *should* live and not having notebooks in git being unsupported. I would argue building actual application features on git brings us pretty firmly into the latter category.<br>

<br>
</div>The approach I suggested depends only on one IPython feature: per-cell<br>
meta-data.  I don't think that will go away any time soon.  The<br>
solution is bolted on top, so it does not rely on any support inside<br>
of IPython.  Also, you can then choose which configurations to run and<br>
generate your output.  In the end, you'll still have to compare the<br>
output somewhat manually (even though we can potentially track the<br>
outputs via version control too, making things easier).<br>
<div class="HOEnZb"><div class="h5"><br>
Stéfan<br>
_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Gabriel Becker<br>Graduate Student<br>Statistics Department<br>University of California, Davis<br>
</div>